Journal Qt 4.5 "Tech Preview" disponible

Posté par (page perso) .
Tags : aucun
17
21
oct.
2008
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
  • # Impressionnant le rythme de sortie des versions !

    Posté par (page perso) . Évalué à 5.

    Qt-4.4 qui apportait déjà énormément d'améliorations est sortie en mai 2008. Ils carburent à la coke c'est pas possible :p
    • [^] # Re: Impressionnant le rythme de sortie des versions !

      Posté par (page perso) . Évalué à 1.

      C'est clair.

      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 (page perso) . Évalué à 10.

        Bon, je pourrais développer pendant des heures et je te demande bien sûr pas de me croire sur parole mais wxWidgets est vraiment vraiment vraiment en dessous de Qt4.
        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 (page perso) . Évalué à 8.

        alors... euh ... bon... un bon gros troll pour le mardi.

        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 (page perso) . Évalué à 6.

          Qtdesigner... pas mal pour faire rapidement un gabarit

          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 (page perso) . Évalué à 6.

        > Ah, dur de choisir un Toolkit!

        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 (page perso) . Évalué à 5.

          Il y a CodeGear C++ Builder

          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 (page perso) . Évalué à 3.

            Voila ce que donne une recherche "C++ Builder" sur une des mailing-list de Trolltech
            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 (page perso) . Évalué à 3.

              Oui, je sais... Ca marche pas, et c'est pas prêt de le faire... Comme quoi, Wx est peut-être à la traine, mais il a l'avantage d'être plus universel (on peut pas tout avoir...) même aujourd'hui (Qt était compatible à l'époque de la "grandeur" de Borland, mais plus maintenant... Et ça va me bouffer trop de temps d'esayer de le rendre compatible), comme quoi il faut pas trop cracher sur Wx, il a aussi quelques avantages même si ils sont faibles ;-)

              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 (page perso) . Évalué à 3.

                Borland onsenfoucestpaslibre :-)

                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 (page perso) . Évalué à 3.

                tu n'as pas gouté à la joie du C++ et des compilo multiples
                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 . Évalué à 1.

          (GLib/GTK+ par comparaison ne compile pas avec Visual C++)

          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 . Évalué à 5.

            GTK+ (et gtkmm) est vachement limité quand même par rapport à Qt. Il faut se trimballer des dizaines de libs externes à côté pour avoir les mêmes fonctionnalités.
            • [^] # Re: Impressionnant le rythme de sortie des versions !

              Posté par . Évalué à 1.

              Pour moi ce n'est pas une limitation, c'est une flexibilité. Tout fourrer dans une seule librairie ce n'est pas ce que j'appelle de la programmation modulaire. un système Gtk n'est pas plus chargé en mémoire qu'un système Qt, il faut arrêter avec les préjugés.
              • [^] # Re: Impressionnant le rythme de sortie des versions !

                Posté par (page perso) . Évalué à 5.

                Tout fourrer dans une seule librairie ce n'est pas ce que j'appelle de la programmation modulaire

                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 . Évalué à 1.

                  Je ne parlais pas de Qt là... j'ai jamais dis que Qt n'était pas modulaire. Je répondais juste en disant que le fait de devoir dépendre de librairie externes à Gtk pour avoir certaines fonctionnalités n'était pas un problème de mon point de vue.
                  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 . Évalué à 8.

                    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 ...)

                    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 (page perso) . Évalué à 4.

            Signal/Slot en c++ natif c'est bien plus propre de mon point de vue.

            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 (page perso) . Évalué à 10.

              > Un exemple est la bête boite d'ouverture de fichier, une horreur pour quiconque utilise Windows.
              >


              Et pas que pour les utilisateurs de Windows d'ailleurs...

              Hop là --> [] !!
            • [^] # Re: Impressionnant le rythme de sortie des versions !

              Posté par . Évalué à 1.

              Franchement, à part la boite de dialogue d'ouverture de fichier sous windows, y a pas grand choses qui change.
              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 . Évalué à 8.

                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é).

                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 (page perso) . Évalué à 2.

            J'ai compilé Glib/Gtk+ ainsi que Glibmm/Gtkmm sous visual c++ y a pas plus de 3 mois
            Désolé je ne savais pas que ça avait changé.
          • [^] # Re: Impressionnant le rythme de sortie des versions !

            Posté par (page perso) . Évalué à 9.

            Signal/Slot en c++ natif c'est bien plus propre de mon point de vue.

            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 (page perso) . Évalué à 3.

              Qt slot/signal a une syntaxe simple c'est vrai mais boost::signal (meme genre que les slots/signaux de gtkmm) a aussi des avantages, je l'ai trouvé plus puissant et moins contraignant. Par exemple Qt slot/signal ne permet pas de mettre des parametres par defaut dans les signaux, pas de verification a la compilation mais seulement au runtime ect... alors que boost n'a pas ses limitations.

              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 . Évalué à 4.

            Signal/Slot en c++ natif
            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 . Évalué à 3.

              Je crois que ce qu'ils veulent dire, c'est que Qt utilise un outil externe à C++ pour gérer ses signaux/slots (le fameux MOC) alors que Boost et Gtk se servent exclusivement des macros/templates du C++.

              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 . Évalué à 3.

              Le moc n'est qu'un préprocesseur évolué. Le code qu'il produit est du code C++ tout ce qu'il y a de plus standard. Le code ajouté par moc permet de faire la colle entre les signaux/slots et assurer d'autres choses comme l'introspection.

              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 (page perso) . Évalué à 2.

                C'est une des raisons (je l'avais oubliée celle la...) qui m'avait fait choisir Wx à l'époque : pas besoin de bidouille externe au code.

                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 . Évalué à 3.

                  Le MOC, ça reste de la bidouille, ce n'est pas standard C++.

                  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 (page perso) . Évalué à 6.

                    Tout à fait.

                    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 (page perso) . Évalué à 3.

                      OK, OK, j'ai compris :)
                      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 . Évalué à 2.

                        Il s'intègre très bien dans le process, dès lors que tu acceptes des outils externes et non-standards comme qmake (lequel te génère un joli Makefile tout bien comme il faut qui prendra en compte les appels au MOC, ou bien un joli projet XCode si tu es sur Mac, etc.)

                        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 . Évalué à 5.

                        Tout résistance est inutile. Dès que tu vas tester Qt, tu vas nous rejoindre! ;-)
  • # Dépêche ?

    Posté par . Évalué à 2.

    Ce serait un journal de patrick_g, je dirais passe encore. Mais bon, là ça vaut bien une dépêche, non ? (de seconde page ! :p)
    • [^] # Re: Dépêche ?

      Posté par (page perso) . Évalué à 6.

      Du calme, du calme... C'est une "Tech Preview", ne l'oublions pas.

      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 . Évalué à 3.

        Pour ça que je disais seconde page ;-).
        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 à ceux qui les ont postés. Nous n'en sommes pas responsables.