Suite des précédents journaux sur le sujet :
http://linuxfr.org/~tanguy_k/27173.html (QGtkStyle désormais inclue dans Qt-4.5 !)
http://linuxfr.org/~tanguy_k/27239.html (Sortie de Qt-4.4.2 + des infos sur Qt-4.5)
La "Tech Preview" de Qt-4.5 vient de sortir
http://labs.trolltech.com/blogs/2008/10/21/same-old-same-new(...)
Rapidement :
- Amélioration de QtWebKit
ajout du support des plugins Netscape (donc support de Flash), du son et de la vidéo via Phonon
- Support Mac OS X 64bits avec passage de l'API Carbon vers l'API Cocoa
Désormais l'intégration de Qt sous Mac devrait être parfaite
- Amélioration importante des performances
Avec notamment un système de backends pour la partie graphique (paint engine)
Il y a désormais un backend OpenGL (!)
- Amélioration du support Windows CE
oui Qt fonctionne aussi sous Windows CE :-)
- Amélioration de QtTest avec l'ajout d'outils d'analyse de performance (benchmarking)
- Ajout du support de XSL-T
- Ajout du format OpenDocument (ODF) en écriture
- Ajout de QGtkStyle pour une intégration parfaite des applis Qt sous GNOME/GTK+
cf précédent journal http://linuxfr.org/~tanguy_k/27173.html
désolé pour les trolls :p
- Amélioration de Qt Designer et Linguist
Plus d'info ici : http://labs.trolltech.com/blogs/2008/10/16/new-features-of-q(...)
- Et pleins d'autres trucs déjà plus ou moins évoqués
Par contre aucune info sur un éventuel système d'animation façon Enlightenment cf http://linuxfr.org/comments/967104.html#967104
A noter aussi que Qt est en train d'être porté sur la plateforme S60 de Nokia
http://labs.trolltech.com/blogs/2008/10/16/new-features-of-q(...)
Nokia S60 est très répandu et utilise l'OS Symbian http://en.wikipedia.org/wiki/Nokia_S60
Pour télécharger Qt-4.5 "Tech Preview" c'est ici :
http://trolltech.com/developer/preview-qt-4.5
J'imagine que la version finale sortira pour la fin de l'année
Journal Qt 4.5 "Tech Preview" disponible
21
oct.
2008
# Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . Évalué à 5.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Zenitram (site web personnel) . Évalué à 1.
J'hésitais pas mal entre WxWidgets (que je préfère pour le moment, car plus "look n feel" de l'OS et plsu de compilos supportés), mais Qt s'améliore de plus en plus, et maintenant que le Troll "Qt c'est pas libre, pas de version libre pour Windows" m'a enlevé la partie bloquante de mon hésitation il reste que Borland c++ n'est pas supporté à mon souvenir, quid d'autres compilateurs sur d'autres machines exotiques? WxWidgets a l'air de supporter plus de compilateurs), et surtout WxWidgets n'avance pas des masses (port Mac à la traine par exemple, utilisant une vieille API...), mon coeur balance... Ah, dur de choisir un Toolkit!
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Guillaume Denry (site web personnel) . Évalué à 10.
Je ne vois pas comment on pourrait le choisir aujourd'hui de façon pérenne en face Qt4, sauf pour des raisons de licence...
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par djibb (site web personnel) . Évalué à 8.
wxWidget n'a rien à voir avec QT... c'est multiplateforme pour l'afficahge des fenetres mais c'est tout...
QT, c'est multiplateforme pour TOUT objet Qt.
jmixplik :
tu veux faire une video, jouer un son... si tu utilises le format de fichier QT, tu t'occupes de rien... Qt gère pour toi sous win ou mac ou linux.
Qtdesigner... pas mal pour faire rapidement un gabarit
QtLinguist... comment gérer les traductions en 4 secondes (sérieusement...)
Bref, pour tout projet multiplateforme qui veut tenir dans la durée, pour le moment, je ne vois pas d'autres choix que Qt, à part le 'j'aime pas le style'.
Pour tous les autres arguments informatiques, la comparaison n'est pas tenable.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Je me méprends peut-être sur le sens de "gabarit" mais ça veut dire que tu t'en sers que pour des maquettes de tes écrans ?
Personnellement je trouve que c'est un outil qui fait gagner énormément de temps dans la conception visuelle même à terme dans une application, pas seulement au maquetage.
Personnellement j'en ai soupé de décrire mes écrans à la main avec des instructions et de taper des kilomètres de layouting....
Bien sûr y'a des cas où on peut pas utiliser Designer, mais pour tout le reste, c'est du bonheur. Surtout dans la façon dont c'est "modularisable".
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . Évalué à 6.
Au contraire c'est vraiment pas du de choisir !
J'ai souvent lu que WxWidgets c'était pas vraiment pas le top (API façon MFC vieillotte, difficulté à obtenir une GUI propre sur chaque OS...). Par exemple VLC est passé de WxWidgets à Qt sans aucun regret du coté des devs (cf mailing-list).
Pour ce qui est du support des compilos, Qt supporte tous les compilos récents : GCC, MinGW, Visual C++ (MSVC > 7.1), Intel CC...
http://trolltech.com/developer/supported-platforms
(GLib/GTK+ par comparaison ne compile pas avec Visual C++)
Pour ce qui est de Borland C++, c'est un compilo mort depuis 10 ans
http://en.wikipedia.org/wiki/Borland_C%2B%2B
Il y a CodeGear C++ Builder http://en.wikipedia.org/wiki/C%2B%2B_builder
Mais ce n'est apparemment pas supporté par WxWidgets non plus
http://www.wxwidgets.org/about/feature2.htm
Après googlage, C++ Builder ne fonctionnerait pas avec d'autres bibliothèques externes C/C++ car il n'est pas fait pour.
Bref si tu veux faire du multiplateforme en C++, utilise Qt, t'en seras très content.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Zenitram (site web personnel) . Évalué à 5.
Bon, OK, j'ai oublié le "Builder", mais c'est le même (même origine du code, sauf qu'à un moment c'est plus gratuit)
WxWidgets le supporte bien (je compile avec en ce moment :) )
De plus la version 10 (2005) a bien été updatée, et supporte tout ce qu'il y a de plus C++ standard, j'ai déjà compilé plein de choses non prévues pour (quand on passe les code Linux only qui compilent pas sous Visual C++ non plus, et quand on passe les code Visual C++ only...).
Et je l'aime bien, c'est tout (je le préfère à Visual C++ pour le déboguage, et qu'on ne me parle pas de GDB, hein, c'est comme comparer les machines distantes de 10 ans...), question d'habitude... (je précise, pour éviter les troll, que mon code compile aussi sous GCC, et ce sur plusieurs architectures allant du PPC en BigEndian à la petite machine Sparc, je fais attention hein... Juste que j'utilise ce que je trouve de meilleur pour moi, sans obliger les autres dans leur choix compilo/OS/CPU), et changer de compilo suivant que je fais du code non GUI (très portable) ou du GUI (moins portable), c'est lourd.
Mais bon, Borland, après avoir un peu rattrapé son retard, repart pour être à la traine (absence de support x64 et C++0x), donc bon, c'est effectivement pas forcement un critère fort maintenant.
Le critère qui m'avait bloqué à l'époque de mon choix initial était que Qt n'était pas disponible pour Windows (version libre), ce qui pour un toolkit multi-OS enlève 95% de la cible... Et maintenant, c'est dur de basculer, poids de l'habitude... Quelle idées aussi ils ont eu de ne pas mettre en GPL dès le départ!
Bref si tu veux faire du multiplateforme en C++, utilise Qt, t'en seras très content.
A force, je vais me laisser sans doute tenter... Par l'abandon de Wx et Borland conjointement sans doute! ça, c'est la force des normes standards avec beaucoup d'intervenants : je peux changer complètement d'environnement de travail sans perdre mon code, c'est ce que j'aime dans le C/C++! (quoi? un autre troll C/C++ vs reste du monde? Non, pas moi... :) )
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . Évalué à 3.
http://www.google.com/search?sitesearch=lists.trolltech.com%(...)
pas tres folichon :/
Tu peux toujours essayer de compiler Qt avec C++ Builder, dans QtGlobal il y a bien Q_CC_BOR cf http://doc.trolltech.com/main-snapshot/qtglobal.html#Q_CC_BO(...) et il y a aussi un makespec win32-borland
Mais je doute que les versions récentes de Qt compilent avec :/
http://www.developpez.net/forums/d609411/c-cpp/bibliotheques(...)
En revanche il est peut etre possible que Qt compilé avec MSVC fonctionne sous C++ Builder. En effet après il reste juste les .h et .dll/.lib à faire fonctionner.
Qt compilé avec MSVC http://qt.windows.binaries.googlepages.com/index.html (Trolltech fournit seulement Qt compilé sous MinGW)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Zenitram (site web personnel) . Évalué à 3.
En revanche il est peut etre possible que Qt compilé avec MSVC fonctionne sous C++ Builder. En effet après il reste juste les .h et .dll/.lib à faire fonctionner.
Oh toi, tu n'as pas gouté à la joie du C++ et des compilo multiples : on peut certes utiliser un compilo A avec une lib venant d'un compilo B en C (A, B, C... Pas fait exprès, désolé :) ), mais on ne peut pas le faire avec du C++ (la décoration des méthodes ayant le même nom et des constructeurs étant différente, le compilo ne retrouve pas ses petits). Déja qu'avec le même compilo c'est dur (cf migration de GCC 3.3 --> 3.4 de l'époque...) C'est pour ça que je fourni un binding C avec ma DLL/Shared Object, pour les gens n'ayant pas le même compilo que moi, et que je diffuse la DLL provenant du compilo de chez MS (99% des utilisateurs ont ça :) ).
Bref, bref, le temps que l'idée murisse et que je fasse l'effort de migrer mon GUI actuel en Qt... C'est un effort psychologique aussi de jeter ce qu'on a fait avec un autre toolkit, c'est pas si facile, mais l'idée fait son chemin ;-)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Gof (site web personnel) . Évalué à 3.
Plus sérieusement, rien t'empêche d'essayer de compiler Qt avec Borland et d'éventuellement corriger les erreurs toi même (tu peux le faire, c'est libre) (et tu peux même envoyer tes patch à Trolltech^WNokia)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . Évalué à 3.
Il me semblait que sous Windows il y avait beaucoup moins de problème car les compilos les plus courants "comprennent" le format généré par Visual C++. En même temps j'ai jamais essayé, donc si tu dis que ça marche pas, je te crois :p
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par ecyrbe . Évalué à 1.
Voilà une assertion bien trompeuse. J'ai compilé Glib/Gtk+ ainsi que Glibmm/Gtkmm sous visual c++ y a pas plus de 3 mois.
De mon côté de prefaire de loin la programmation avec gtkmm et glade pour faire une UI que Qt.
Signal/Slot en c++ natif c'est bien plus propre de mon point de vue.
Sans compter que gtkmm tire réellement parti des templates, avec une API tout aussi bien pensée que celle de Qt.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Narishma Jahar . Évalué à 5.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par ecyrbe . Évalué à 1.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . Évalué à 5.
Ce n'est pas parceque Qt propose un ensemble de librairies cohérentes, bien foutues et bien documentées que ce n'est pas de la programmation modulaire, au contraire.
http://doc.trolltech.com/main-snapshot/modules.html
Si tu ne fais pas de SQL, tu ne depends pas de QtSQL, pareil pour QtWebKit, QtGui, Phonon, QtXML, QtNetwork ect...
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par ecyrbe . Évalué à 1.
Exemple, Gtk ne possède pas de d'api video/son. Pour moi ce n'est pas un problème. Si besoin, j'utilise Gstreamer qui a une api Glib like... et les exemples sont légions (Clutter, GtkWebkit ...) Je ne vois pas le problème à ce que ce ne soit pas dans Gtk qui s'occupe du GUI et uniquement du GUI...
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Larry Cow . Évalué à 8.
Et bien entendu, toutes ces librairies tierces sont supportées de manières égales sur toutes les plateformes majeures actuelles? Rappel d'un détail de la news : Qt tourne sur WindowsCE et est en cours de portage vers Symbian.
Et même si je suis en train de ranger mon plus gros reproche à l'écosystème Gtk (l'obligation d'utiliser un serveur X sous MacOSX), force est de reconnaître que pour faire une application graphique un peu riche qui tourne sur Mac/Linux/Windows, y'a guère que Java qui arrive à la cheville de Qt. C'est théoriquement possible en Gtk&co, mais il va toujours te manquer la bonne version de telle bibliothèque pour faire tel truc. Avec Qt, tu as tout intégré et ce qui marche sur la 4.X de telle plateforme marchera sur la même 4.X d'une autre plateforme.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Zenitram (site web personnel) . Évalué à 4.
Allez, je saute dans le troll : bon, GTK+, c'est quand même un pas un toolkit digne de ce nom : il ne fait que recopier le comportement Linux sous Windows, ce n'est pas ce qu'on peut appeler un truc ergonomique au sens "utilisable par une personne ayant l'habitude de son OS", c'est rendre exécutable une appli Linux avec le même design que sous Linux, mais pas un Toolkit (qui permet de programmer pour différente plate-forme sans heurter les habitudes de nos utilisateurs)
Si on veut porter salement une appli Linux (Gnome?) sous un autre OS, pourquoi pas. Si on veut faire un outil qui s'adapte à l'utilisateur, GTK n'est pas adéquat. Un exemple est la bête boite d'ouverture de fichier, une horreur pour quiconque utilise Windows.
Wx et Qt sont comparables, GTK+ est hors jeu quand on parle d'outil vraiment ergonomiques (=qui n'impose pas une vue Linux à quelqu'un qui n'en veut pas). Et finalement, à force qu'on me le répète, il y a de moins en moins de concurrent dans le secteur, Qt domine vu l'évolution de Qt... Espérons qu'ils ne s'endormiront pas sur leurs lauriers.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par GCN (site web personnel) . Évalué à 10.
>
Et pas que pour les utilisateurs de Windows d'ailleurs...
Hop là --> [] !!
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par ecyrbe . Évalué à 1.
De plus même MS ose changer sa boite de dialogue d'ouverture de fichiers dans Ms Office 2007 .... et celà n'a pas l'air de troubler leurs utilisateurs.
Alors je trouve que tu y vas fort en disant que ce n'est "pas un toolkit digne de ce nom". Tes propos sont un poil trop rude quand même.
J'ai plusieurs applications au boulot que j'ai développé avec gtkmm. Et je dois dire que j'ai gagné un temps monstreux en temps de développement/debuggage par rapport à WxWidgets.
Pour moi ça c'est le gage d'un bon toolkit. Un toolkit qui me laisse construire une interface graphique en un rien de temps et qui fonctionne sous Linux/Windows/ voire Mac (jamais testé).
Je n'ai évidement rien contre Qt, c'est un très très bon toolkit aussi.
mais je suis un puriste du c++ et donc je préfaire un solution native aux Signal/Slot. Je n'ai rien d'autre à reprocher à Qt. Juste une histoire de gout.
Je pense que Gtkmm est aussi productif que Qt (en tout cas pour mes besoins).
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Larry Cow . Évalué à 8.
Ben justement. Le Mac. Parlons-en. Comme je l'ai dit plus haut, on a théoriquement depuis peu une version "native" de Gtk+ sur MacOSX. Mais il y a encore un mois, si tu voulais faire tourner une application Gtk sur Mac, tu étais contraint (sauf à utiliser du "très instable", et à ma connaissance seul Avidemux s'y était risqué, et seulement récemment) de faire tourner ton application sous X.
Et là, on touchait du doigt ce qu'on te fait remarquer ci-dessus : une application Gtk ne fait strictement _aucun_ effort pour s'adapter à son environnement. D'ailleurs, sur Mac, elle est exactement identique à sa version Linux, jusqu'au comportement du focus (qui du coup jure terriblement avec le reste des applications Mac). Sous Windows, encore, les applis proposent généralement de s'installer avec Gtk-WIMP (le thème "Windows" de Gtk) qui limite bien la casse (sauf sur le dialogue d'ouverture). Mais sur Mac, nada. C'est pratique en ce sens que ça te permet de faire tourner ton application avec un minimum d'efforts (pas besoin d'installer MinGW ou autre, sur Mac), mais par contre ça reste une bidouille pour dépanner : ton appli n'aura jamais l'air "vraie".
L'intégration Qt n'est certainement pas parfaite non plus sur Mac, mais la différence est beaucoup plus subtile.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . Évalué à 2.
Désolé je ne savais pas que ça avait changé.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Gof (site web personnel) . Évalué à 9.
Bon moi aussi je saute dans le troll.
Le troll de ceux qui son prêts à taper plus de lignes de code, et du code plus compliqué au profit de la prétendue « pureté »
Les même personnes qui choisissent d'utiliser la STL, beaucoup moins facile et pratique à utiliser que les conteneurs Qt, pour cette même sacro-sainte « pureté »
Purté qui n'apporte rien de toute façon, car Qt ne va pas rendre le code moins portable ou moins standard, bien au contraire.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . Évalué à 3.
Et puis moc pete regulierement les couilles a la compilation, les mots cles de Qt ne sont pas souvent reconnus par les IDE ect...
Si moc pouvait disparaitre ca serait pas un mal, quitte a rajouter quelques macros pour garder la même simplicité d'écriture. Il va surement y avoir des changements quand C++0x sera supporté.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Anthony Jaguenaud . Évalué à 4.
Depuis quand les signaux/slots sont du C++ ? C'est une extension de QT pour se faciliter les choses, et fonctionner sur de nombreux compilateurs.
On passe par une phase de génération de code.
Mes connaissances en QT sont proche de zéro, merci d'infirmer mes dires si ceux-ci s'avèrent faux.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Larry Cow . Évalué à 3.
Ceci étant dit, il ne faut pas oublier que :
- Qt s'est mis à utiliser le MOC parce qu'à l'époque, C++ seul (ses compilateurs, du moins) n'était pas au point. Conclusion : ils ont largement eu le temps de peaufiner leur implémentation "externe", ce qui peut influer sur sa qualité par rapport aux solutions "natives" (mais aussi plus jeunes) de la "concurrence".
- Comme remarqué plus haut, les solutions natives ne sont pas forcément des modèles d'élégance, si on fait abstraction de leur indépendance à un outil externe. La STL est peut-être un superbe exemple d'utilisation des templates, mais ça a tendance à favoriser un code extrêmement peu intuitif (et des messages d'erreurs encore pires) pour un non-templateux. Le code équivalent en Qt+MOC peut paraître beaucoup plus lisible, notamment pour un non-Cpluspluseux ;)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par sanao . Évalué à 3.
En ce qui me concerne, le moc est un avantage car il permet de simplifier grandement la syntaxe C++ que le développeur utilise. Le reste est dans la documentation : http://doc.trolltech.com/4.4/moc.html
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Zenitram (site web personnel) . Évalué à 2.
Le MOC, ça reste de la bidouille, ce n'est pas standard C++.
Bon, dès que je me motive, je regarde si ça ne me bloque pas à l'utilisation (j'ai jamais testé Qt en pratique)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Larry Cow . Évalué à 3.
Si on va par là, un IDE non plus ça n'est pas "standard C++". Les "compilateurs d'UI" (UIC sous Qt, d'autres noms ailleurs) qui transforment un fichier de description d'interface en code non plus. Les IDL-compilers de Corba (pourtant très utilisé dans le monde Gnome, fut un temps) non plus. Et ainsi de suite.
Un puriste du C++ pourra effectivement trouver à y redire. Un pragmatique, à plus forte raison s'il a été amené à manipuler des langages plus souples que l'ami ++, risque fort d'y prendre goût ;)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Gof (site web personnel) . Évalué à 6.
Un compilateur c'est aussi de la bidouille ? Les vrais, ils codent en binaire dirrectement, sans bidouille ? Pas besoin d'assembleur ou de compilateur ?
Le moc de Qt est là juste pour simplifier la vie du programmeur en générant du code rébarbatif que le programmeur n'a donc plus à taper lui même.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Zenitram (site web personnel) . Évalué à 3.
Je m'armerai de tests de la chose (si il s'intègre bien dans le process...) avant de le critiquer!
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par Larry Cow . Évalué à 2.
Sinon effectivement, si tu tiens absolument à construire ton projet avec les scripts maison que tu peaufine amoureusement depuis Linux 2.0.36, l'utilisation du MOC va te demander un surcroît de travail.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par sanao . Évalué à 5.
# Dépêche ?
Posté par Aldoo . Évalué à 2.
[^] # Re: Dépêche ?
Posté par Zenitram (site web personnel) . Évalué à 6.
Plutôt préparer une dépêche au calme, basée sur ce joli journal, pour qu'elle soit prête à balancer le jour de la sortie officielle!
[^] # Re: Dépêche ?
Posté par Aldoo . Évalué à 3.
Et puis, avoir une dépêche avant la sortie d’un logiciel, ça nous changerait, non ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.