Journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5

Posté par (page perso) .
Tags : aucun
32
23
sept.
2008
Qt-4.4.2 vient de sortir, juste des corrections de bugs, voici les changements : http://trolltech.com/developer/resources/notes/changes/chang(...)

Pour ce qui est de la futur version Qt-4.5, ça avance et ça va être que du bon :

- Le support Cocoa est maintenant dans la futur version 4.5 :
http://labs.trolltech.com/blogs/2008/09/22/cocoa-news-and-vi(...)
http://labs.trolltech.com/blogs/2008/06/09/second-cocoa-alph(...)
Pour rappel, Qt utilise jusqu'à maintenant l'API carbon http://en.wikipedia.org/wiki/Carbon_(API)
Celle-ci n'est pas compatible 64bits contrairement à Cocoa et est un peu a l'abandon par Apple d'apres ce que j'ai compris (Carbon etait avant tout la pour permettre la transition entre MacOS 9 et X) http://en.wikipedia.org/wiki/Cocoa_(API)
Concrètement, Qt-4.5 sera donc parfaitement intégré à MacOS X, ce qui n'était pas tout a fait le cas avec les précédentes versions de Qt

- Qt-4.5 sera encore plus rapide au niveau de l'affichage sous Windows
http://labs.trolltech.com/blogs/2008/09/22/sorry-guys/
D'autres optimisations sont a prevoir egalement : http://labs.trolltech.com/blogs/2008/08/06/in-the-flow/

- Qt-4.5 devrait améliorer l'affichage des polices et se rapprocher de GTK+ au niveau de l'aspect des polices
http://labs.trolltech.com/blogs/2008/09/01/subpixel-antialia(...)
http://labs.trolltech.com/blogs/2008/08/28/font-anatomy/

- La couche réseau sera plus performante avec l'ajout d'un système de cache
http://labs.trolltech.com/blogs/2008/08/04/network-cache/

- QTextDocument permettra l'export au format OpenDocument (ODF) (mais pas la lecture)
http://labs.trolltech.com/blogs/2008/08/06/opendocument-form(...)

- QWebKit va être amélioré avec le support des plugins et donc notamment de Flash

- On pourra enfin fermer individuellement les tabs d'un QTabBar
http://labs.trolltech.com/blogs/2008/07/02/some-qtabbar-qtab(...)
Il etait temps...

- Pour rappel, QGtkStyle fera partie de Qt-4.5
http://linuxfr.org/~tanguy_k/27173.html

- Cette liste n'est pas exhaustive

D'après ce que j'ai compris, une première version (Technology Preview) de Qt-4.5 devrait être disponible d'ici quelques semaines.
En revanche je n'ai pas d'infos sur la date de sortie de Qt-4.5, surement pour la fin de l'année.

Pour ceux qui avaient encore un doute : Qt est tout simplement devenu avec le temps le meilleur toolkit graphique tous langages et plateformes confondus.
  • # Animation API (Qedje ?)

    Posté par . Évalué à 2.

    Il ne faut pas oublier l'API pour les animations qui semble être de la partie pour Qt 4.5. D'après les réponses de Thiago Macieira aux commentaires d'un de ses posts sur son blog [1], on subodore que cette mystérieuse API serait basée sur Qedje [2,3,4]. On en saura sans doute bien plus le 14 octobre prochain lors de la conf "Qt Technology Roadmap" des qt developer days 2008 [5].


    [1] http://labs.trolltech.com/blogs/2008/09/18/repeat-after-me-t(...)
    [2] http://dev.openbossa.org/trac/qedje
    [3] http://labs.morpheuz.eng.br/blog/01/08/2008/qedje-init/
    [4] http://labs.morpheuz.eng.br/blog/21/08/2008/plasmoid-with-qe(...)
    [5] http://trolltech.com/qtdevdays2008/technical
    • [^] # Re: Animation API (Qedje ?)

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

      QEdge est un projet fait par des personne n'aiyant rien à voir avec Trolltech (ou très peu)
      QEdge n'est donc pas cette mistérieuse API.
      Et puis rien est encore sûr concernant l'intégration de l'API d'animation dans Qt 4.5
  • # Choix

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

    Je préfère le visuel GTK, mais quand il s'agit de coder, QTdesigner, c'est quand même franchement mieux que glade. Enfin, j'ai pas fait de GUI depuis des années, mais je doute que le premier ait stoppé son évolution et que l'autre se soit envolé. Quoique la poussée Ubuntu a ptet permis un apport en développeurs (et oméga trois) conséquent...
    • [^] # Re: Choix

      Posté par . Évalué à 5.

      Je ne comprend pas ce que tu entends par "visuel GTK". Visuellement, avec un style tel que QGtkStyle, quelle est la différence avec GTK en natif?
      • [^] # Re: Choix

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

        Ben, comme je le disais, ça fait longtemps.
        Ensuite, tu parles justement de "style" par opposition à "natif"...
        Enfin, personnellement, depuis une dizaine d'année, je n'utilise que des applis GTK, et des QT que très sporadiquement (genre, sur une machine d'ami, lors du premier log in sur une machine d'université, etc), donc je n'ai pas trop d'expérience à ce niveau pour dire ce qui est bien ou ne l'est pas. Disons que j'ai un biais ancestrale qui penche pour GTK.
        • [^] # Re: Choix

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

          > Disons que j'ai un biais ancestrale qui penche pour GTK.

          C'est étrange comme c'est souvent chez les personnes aimant GTK...

          Le truc c'est que ça date souvent de l'époque ou qt était pas totalement libre (alors que c'est fini depuis un moment...)
          C'est graphiquement bien, surtout avec les ajouts de qt4.5 (même si celui-ci n'est pas encore vraiment là)
          C'est techniquement bien, un modèle object bien foutu (pour du C++ c'est impec)
          C'est très vaste.

          En gros, y a-t-il des arguments objectifs contre Qt ou pour GTK ?

          (à part openoffice et firefox hein parce que bon...)
          • [^] # Re: Choix

            Posté par . Évalué à 5.

            (à part openoffice et firefox hein parce que bon...)
            OpenOffice dispose dans sa VCL d'une abstraction au toolkit sous-jacent. Ce n'est donc pas un argument.
            Firefox utilise XULrunner, dont un portage en Qt est en cours aussi. Prochainement, cela ne devrait donc plus être un argument (sauf si le port est à nouveau abandonné, comme cela s'est déjà produit)
          • [^] # Re: Choix

            Posté par . Évalué à 4.

            En gros, y a-t-il des arguments objectifs contre Qt ou pour GTK ?

            Est-ce que "Je programme en C" ca te va comme argument ? Promis le jour où il y a un binding C (officiel) pour Qt j'essaie pour voir.

            PS: ce message n'est pas une incitation au troll C Vs C++ ou même PI Vs POO, c'est juste que moi j'aime le C, c'est le langage avec lequel je suis le plus à l'aise, et c'est avec lui que je veux programmer lorsque je fais cela pour le plaisir sur mon temps libre (pour un projet professionnel le langage est choisi sur d'autres critères que mes goûts personnels). GTK avec son très grand nombre de binding permet à chacun d'en faire de même quelque soit ses goûts en matière de programmation.
            • [^] # Re: Choix

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

              > Est-ce que "Je programme en C" ca te va comme argument ?

              Ha mais tout à fait et même je l'aprouve.
              Cette raison je la comprend très bien (qui n'a pas choisi au moins une fois un toolkit / framework en fonction du langage qu'il connait ?)
              (Celle que je comprend moins c'est GObject mais bon...)

              Pour ce qui est de binding, avec Qt (donc en C++) + les binding python, ruby, java (perl je sais plus) même si ça ne couvre pas tous les langages et qu'il y en a surement plus de supportés en GTK, je trouve ça déjà pas mal.
              • [^] # Re: Choix

                Posté par . Évalué à 7.

                @CrEv
                Je me rend compte que j'ai oublié les smileys dans ma première phrase, du coup j'ai l'air vindicatif alors que je voulais sonner cynique ^^;

                @tanguy_k
                Le coup du binding C était une boutade (je sais j'ai oublié les smileys ^^), j'avais déjà vu le binding C expérimental cité un peu après ton message, c'est pour ca que j'avais précisé "officiel", je n'ai certainement pas l'intention de me lancer dans un dev, même pour le fun, en reposant sur un truc aussi peu pérenne (et peu abouti au passage)

                @sanao
                J'avais bien précisé que je ne voulais pas lancer de troll à ce sujet, mais bon je vais essayer de te répondre quand même: J'ai en effet quelques soucis d'accointance avec la POO et particulièrement le C++.

                - Pour la POO, c'est simple, il y a déjà en effet on va dire "les goûts et les couleurs". Pour moi, il est plus facile, plus naturel, de raisonner sur "une combinaison complexe d'élements simples" plutôt que sur "une combinaison simple d'élements complexes".

                Explications: le C, c'est des fonctions, avec des entrés/sorties, un retour, et code séquentiel dedans. Un bon codeur en C écrivant des fonctions relativement courtes, le programme ne sera alors qu'un ensemble de petites briques avec des relations inter et intra niveau.

                Chacune de ses briques étant donc algorithmiquement indépendantes, je peux alors me concentrer individuellement sur chaque brique sans avoir à me soucier des autres briques et surtout sans monopoliser une partie de ma concentration sur des problèmes d'héritage, de surcharge, de constructeur de recopie, etc. Pouvoir travailler de cette manière est pour moi essentiel afin d'obtenir un code robuste et aisément maintenable.

                Bon maintenant, je me doute bien que je n'ai pas vraiment le profile type du développeur de SSII. Dans ce que je programme en (très) gros, 60% c'est de l'appli en ligne de commande, 25% c'est du code noyau, 10% c'est du code très bas niveau (comprendre par là en assembleur (aussi bien coté noyau qu'utilisateur)), et 5% de GUI (et je suis gentil en disant 5% ^^). Et quand je programme, même pour le fun sur mon temps libre, je fais toujours ca à l'ancienne: d'abord une specification fonctionnelle, puis spécification architecturale en couche, puis les algorithmes des différents composants, puis enfin je code ces différents composants des couches les plus basses vers les couches les plus hautes en validant toujours les composants d'une couche avant de passer à une couche supérieure à l'aide de tests automatisés et de jeux de données.

                Mais même moi qui suit un peu un extremiste du développement l'ancienne (voir le paragraphe juste au dessus ^^), je reconnais que dans certains cas la POO peut apporter quelque chose au processus de développement. Il m'arrive d'ailleurs de l'utiliser occasionnellement (python/ruby).

                Le problème que j'ai avec beaucoup de développeurs POO (les javateux en particulier) c'est que comme le dit un dicton anglais, quand on a un marteau, tous les problèmes ressemblent à des clous. Le nombre de fois où j'ai vu l'artillerie lourde objet être utilisée pour un (relativement) petit développement où du fonctionnel aurait donné un code au design plus simple, plus lisible et plus maintenable... le nombre de fois où j'ai vu java utilisé pour un développement dont il est complètement crétin de se farcir une machine virtuelle dans l'environnement d'exécution...

                Si on avait inventé un language parfait pour tous les usages, ca se saurait. On dispose de tout un tas de languages de programmation, et développer (pour moi) c'est aussi savoir choisir le bon outil pour le bon développement. Bien sur on ne peut pas maitriser tous les languages, mais avoir à sa disposition un panel de 2-3 languages qui se complètent c'est pas superflue.

                - Pour le C++, là aussi c'est simple, c'est clairement *TROP* objet ! C'est sûrement très intéressant et très à la pointe en terme de paradigme objet d'un point de vue théorie des langages, mais d'un point de vue pratique ca fait un peu usine à gaz desfois...

                Par exemple, il m'est arrivé de devoir me plonger dans du code C++ (pas écrit pas moi) où j'ai mis un temps fou à m'y retrouver parce que les instanciations de template avec héritage multiple... bonjour l'aspirine... À l'inverse, quand je me suis m'y à coder pour le noyau linux, je m'y suis très vite retrouvé, pourtant c'est pas ridicule comme programme (et pas écrit par moi non plus ^^), mais limiter un minimum la complexité semantique d'un langage pour ne conserver que ce qui apporte vraiment, c'est loin d'être une mauvaise idée, surtout en informatique où ca parait pas idiot de chercher à se concentrer plus sur l'algorithme que sur le langage lui même.

                J'avais aussi jeté un coup d'oeil à Objectiv-C, je trouve que leur paradigme objet est déjà plus raisonnable. Bon par contre la syntaxe est à gerber.

                Pour ce qui est des langages "managés", type JAVA ou C#. Je trouve ca très intéressant (enfin surtout le côté managé, parce que bon l'objet hein... ^_^). Pour du userland, la robustesse, la sécurité et les possibilités d'introspection qu'ils apportent c'est vraiment un plus non négligeable. Le problème depuis l'avènement de ces langages managés, c'est que beaucoup croient qu'il n'est plus maintenant nécessaire de comprendre comment fonctionnent les couches basses d'un ordinateur et encore moins de faire attention à comment on implémente les algorithmes car de toute facon la machine virtuelle passe tout ca dans sa moulinette avant l'exécution.

                Moi je pense réellement que ca apporte quelques choses de maitriser les couches basses (et donc de faire du C), même si après on ne sans sert pas en JAVA. Ca impose une certaine rigueur ensuite bénéfique même pour les langages de plus haut niveau.

                Genre je donne des cours de prog, je fais réimplenter en JAVA un client FTP (sans utiliser d'API de haut niveau, oui c'est réinventer la roue, mais cette dans un but pédagogique). J'ai 2 types d'élèves, des 3ème année d'ingé, pas des informaticiens mais des gars qui ont bouffés du JAVA pendant leur formation et pas des quiches niveau capacités intellectuelles, et des 2ème année d'IUT élec, qui n'ont jamais fait de JAVA (sauf ceux qui en ont fait chez soi sur leur temps libre) et donc qui doivent aussi appréhender le JAVA par la même occasion. Sauf que ces derniers se sont farcis la programmation de micro-controlleur en C et en ASM par le passé, et c'est un secret pour personne qu'implémenter un protocole réseau ca demande d'être rigoureux. Je vous laisse deviner qui s'en sort mieux au final...

                De par les facilités que ces langages apportent, beaucoup pensent qu'on a plus besoin d'être aussi rigoureux et attentif qu'avant pour développer, et bien souvent, à l'issue des formations, au final ce qu'on a formé c'est pas des développeurs mais des pisseurs de code. Mais bon, comme le pisseur de code en JAVA ou C# est très recherché ces derniers temps dans le milieu professionnel (j'ai déjà eu ca en job hein ^^, on a un mois pour torcher une appli pour la refiler au client et encaisser le chèque puis passer au client suivant, au pire si plus tard le client se rend compte de bug on factuera la maintenance du code ^^). On va dire que le marché à les développeurs qu'il mérite ^^
                • [^] # Re: Choix

                  Posté par . Évalué à 3.

                  Je suis tout à fait d'accord avec toi sur le fait qu'il faut également connaître les couches basses du système (comment est gérée la mémoire, la différence entre thread et processus et comment cela est géré par le système, comment fonctionne la communication réseau avec les différentes encapsulation de protocoles, etc...). Il n'est peut-être pas nécessaire d'en savoir assez pour implémenter tout cela, mais au moins de savoir grossièrement ce qu'il se passe quand on utilise certaines choses.

                  Cela permet non seulement de bien faire les choses, mais également de savoir si l'outil que l'on utilise est adapté à la situation et selon les cas, le langage peut être aussi différent que C, C++, Python, Java ou simplement Bash.

                  En ce qui me concerne, je réalise mes développement perso généralement avec Qt en C++ et je suis très satisfait du rapport entre la performance et la facilité de codage/maintenance.

                  Concernant ta remarque sur ta relecture de code en C++ avec instanciations de template avec héritage multiple, cela vient peut être du fait que le code est compliqué (et non complexe) pour pas grand chose. Cela arrive bien souvent (et avec tous les langages) lorsque des personnes codent en ne sachant pas vraiment se qu'ils font ou lorsqu'ils sont pressés par le temps et utilisent une technologie qu'ils ne maîtrisent pas vraiment.
              • [^] # Re: Choix

                Posté par . Évalué à 2.

                Et bé, avec mon précedent message, l'expression "poser un pavet dès le matin" prend un tout autre sens ^^

                @tout le monde
                Vous pensez quoi de VALA ? Ca ressemble à de la POO minimaliste, c'est-à-dire avec juste ce qu'il faut pour développer des GUI, le tout avec une syntaxe à la C. J'ai bien envie de tester, car sur la papier, cela pourrait bien parfaitement me convenir ponctuellement pour de la GUI.
            • [^] # Re: Choix

              Posté par . Évalué à 4.

              Pour la préférence pour le C j'ai du mal à comprendre la raison. C'est l'aspect objet que tu n'aimes pas? Parce que je dois avouer que c'est un paradigme que je trouve bien plus clair que du simple procédural comme le C où on est bien souvent obligé de se trimbaler une grosse structure qui au final revient à un objet.

              Maintenant c'est ma vision des choses et comme on dit, les goûts et les couleurs cela ne se discute pas.

              En tout cas en ce qui me concerne si j'adore Qt4 c'est principalement pour la qualité et l'extrême richesse de la bibliothèque.
            • [^] # Re: Choix

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

              > Promis le jour où il y a un binding C (officiel) pour Qt j'essaie pour voir.

              AMHA Il n'y aura jamais de binding C pour Qt. Mapper Qt qui utilise intensivement le modèle objet par un système procédurale serait à mon avis beaucoup trop compliqué et donnerait un truc bancale.

              Laissons le langage C pour le noyau, les drivers ect...
              Pour les interfaces graphiques, des langages comme C++, Python, Java, C#, Ruby ect... sont infiniment plus adaptés. Ca tombe bien, il y a des bindings Qt pour ces langages.
              Les bindings Python (PyQt) et Java (Qt Jambi) sont considérés comme stables et sont régulièrement utilisés par des applications, en revanche les bindings C# et Ruby ne sont pas encore vraiment utilisés et doivent être surement encore trop jeune.

              Pour moi (je vais me faire moinser, tant pis), le fait que le projet GNOME souhaite à tout prix utiliser le langage C est une hérésie. Et Miguel de Icaza a du bien s'en rendre compte, d'où la création de Mono.

              Bref pour les interfaces graphiques, il est temps d'abandonner le C qui date d'il y a 40 ans pour un truc plus moderne comme Python, le résultat n'en sera que meilleur.
              Pour le web ca fait longtemps que l'on ne fait plus de CGI en C alors admettons que le C est aussi dépassé pour la création d'interfaces graphiques.
              • [^] # Re: Choix

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

                Bref pour les interfaces graphiques, il est temps d'abandonner le C qui date d'il y a 40 ans pour un truc plus moderne comme Python, le résultat n'en sera que meilleur.

                J'adore les gens qui assène des vérité qu'ils sortent d'on ne sais où ?

                c'est marrant mais la plupart des applis gui en C qui marche très bien il y en a un paquet, mais que je trouve ça bien que des bon devs C s'attaque aussi à du GUI et me ponde des application qui sont très performantes, je ne parle pas forcément des applis gtk, mais des applis E17 par exemple emphasis ou exhibit... Laisse les gens qui aiment le C développer dans leur langage de prédilection et arrête avec tes conneries d'hérésies.

                j'aime les belles affirmations pourries :
                Laissons le langage C pour le noyau, les drivers ect... je te signale qu'il y a des gens aussi qui utilise le C++ pour faire ce genre de choses : noyau, driver, etc.
                • [^] # Re: Choix

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

                  > J'adore les gens qui assène des vérité qu'ils sortent d'on ne sais où ?

                  Ma propre expérience + celle de pas mal d'autres dev.

                  > la plupart des applis gui en C qui marche très bien il y en a un paquet

                  Et ben dit toi que si ces applis avaient été développé en Python par exemple, et ben les développeurs auraient été plus vite ou/et auraient ajouté plus de fonctionnalités.
                  C'est comme ça, j'invente rien, n'importe quel dev qui a fait du C et du Python te dira que l'on développe plus vite en Python.
                  Il est par exemple aussi communément admis que l'on développe 2x plus vite en Java qu'en C++ (source : Bruce Eckel).

                  Ca veut pas dire que le C est un mauvais langage ou que les applis codées avec sont mauvaises, ça veut simplement dire que dans pas mal de cas (de plus en plus avec le temps), il est tout simplement inadapté.
                  Tout comme un jour C++, Java, C#... seront surement replacés par des langages plus performants.

                  Libre après aux gens d'utiliser des langages moins adaptés, je vais pas aller les bruler hein ! j'ai longtemps développé en C mais je suis pas marié avec un langage en particulier : j'utilise celui qui semble être le plus adapté pour ce que je veux faire ./
              • [^] # Re: Choix

                Posté par . Évalué à 3.

                il est temps d'abandonner le C qui date d'il y a 40 ans

                D'ailleurs, il est également temps d'abandonner Unix qui est aussi vieux. Passons tous à Vista puis Seven, ça c'est l'avenir !

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Choix

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

                  > il est également temps d'abandonner Unix qui est aussi vieux

                  Ma phrase signifiait pas que "c'est vieux donc c'est nul" mais qu'il y a eu des avancés importante entre le langage C et les langages dit modernes tout comme entre la Ford T et la dernière Renault.

                  D'un autre coté je me sers tous les jours de la vaisselle de ma grand mère, on a pas encore fait mieux, et pourtant dieu sait que ça date !
              • [^] # Re: Choix

                Posté par . Évalué à 1.

                AMHA Il n'y aura jamais de binding C pour Qt.

                Ça a déjà été fait apparemment, mais je ne sais pas ce qu'il en est :

                http://dot.kde.org/1003877941/
                • [^] # Re: Choix

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

                  Oui c'est vrai, mais bon c'était plus du "proof of concept" qu'autre chose.
                  De toute façon l'intérêt est franchement pas évident vu que GTK+ / C existe.
                  • [^] # Re: Choix

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

                    En effet.
                    Qt est plus qu'une bibliothèque graphique c'est un framework comlet.
                    Framework qui utilise à fond le paradigme object.

                    Si c'est juste pour pouvoir avoir le même look, il suffit d'utiliser Gtk et en:GTK-Qt
              • [^] # Re: Choix

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

                Bref pour les interfaces graphiques, il est temps d'abandonner le C qui date d'il y a 40 ans pour un truc plus moderne comme Python, le résultat n'en sera que meilleur.

                Pour après se plaindre que le desktop rame ?! Moi je suis content que GNOME se base sur un langage compilé bas niveau, ce qui garanti un minimum de perf sur une petite machine (notebook ou autres).

                Libre à toi de développer une appli GTK+ ou GNOME en python, c'est l'intérêt même des bindings, sauf qu'un langage script c'est bien pour développer un petit soft mais pas pour un gros projet qui a besoin d'être réactif et d'occuper peu de ressource.
                • [^] # Re: Choix

                  Posté par . Évalué à 4.

                  "Pour après se plaindre que le desktop rame ?! Moi je suis content que GNOME se base sur un langage compilé bas niveau, ce qui garanti un minimum de perf sur une petite machine (notebook ou autres)."
                  C'est pour ça que Gnome commence à inclure des applis codées en Mono ?!?
                  • [^] # Re: Choix

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

                    Tu confonds application utilisateur et desktop. Le noyau de GNOME est en C, cela comprend les multiples librairies et démons (gconfd, gnome-panel, ...) et c'est ce qui permet de proposer une version mobile : http://www.gnome.org/mobile/

                    De toute manière GNOME incluait bien avant Mono des applications en Python, ce qui certes n'aide pas à la réactivité mais c'est un choix de certains développeurs, la grande majorité des applications sont en C/C++.
                • [^] # Re: Choix

                  Posté par . Évalué à 3.

                  C++ et objectiveC sont tous les deux "compilés bas niveau", pas de problème de performance potentiel de ce côté-là.
              • [^] # Re: Choix

                Posté par . Évalué à 2.

                Pourquoi Python?

                Scala me parait bien plus adapté: ça tourne sur la JVM (donc a priori plus performant), c'est statiquement typé avec inférence de type donc moins verbeux que Java ou C++, mieux connu que Vala..

                Oups, c'est pas vendredi, ok je --> []
    • [^] # Re: Choix

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

      Tu parles de Qt Designer et c'est vrai que c'est un outil sympa à utiliser (bien que quelques défauts me gonflent, essentiellement l'éditeur de propriétés que je trouve assez peu pratique). Mais j'aurais tendance à dire que ça n'est que la partie émergée de l'iceberg : tout le toolkit est un vrai bonheur à utiliser, tout est cohérent, unifié, puissant.
      D'ailleurs je crois qu'on peut dire que Qt4 n'a aucun équivalent aujourd'hui en matière de largeur de spectre fonctionnel couvert : GUI, multimédia (avec phonon), bureautique, structures de données puissantes, gestion de l'unicode, gestion des traductions, gestion de la documentation (depuis peu), gestion de webkit, etc.
      C'est un véritable couteau suisse.
      • [^] # Re: Choix

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

        Quel est ton problème avec l'éditeur de propriété ?
        • [^] # Re: Choix

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

          Essentiellement des soucis de visibilité :
          Par exemple, lorsqu'on ouvre une combobox de valeurs pour n'importe quelle propriété, sa largeur (la liste de défilement) est celle de la cellule de valeur, et souvent on ne voit pas entièrement les intitulés des valeurs et il faut alors retailler le formulaire, ou régler la taille des colonnes de l'éditeur. Du coup, je suis constamment en train de retailler des trucs.
  • # Troll

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

    Qt est tout simplement devenu avec le temps le meilleur toolkit graphique tous langages et plateformes confondus

    merde le troll prend pas :/
    • [^] # Re: Troll

      Posté par . Évalué à 10.

      Normal, pour qu'on troll prenne il faut que ce soit un troll pas une réalité ;)
    • [^] # Re: Troll

      Posté par . Évalué à 10.

      Qt, un toolkit graphique?
      C'est très réducteur!

      Autant dire qu'Emacs est un éditeur de texte alors!

      (et vivement vendredi...)
    • [^] # Re: Troll

      Posté par . Évalué à 2.

      Il a deja eu lieu la semaine derniere donc c'est du rechauffe :)
    • [^] # Plate-forme

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

      Pourquoi écrire plate-forme en un seul mot ?
      C'est pour éviter l'accord des mots composés ?
  • # widgets transparents

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

    Au passage, Qt-4.5 permettra aux widgets a l'interieur d'une application d'etre transparent cf http://labs.trolltech.com/blogs/2008/09/23/translucent-widge(...)
    Donc encore plus de bling bling, je crois que notre pote Sarko va etre content :p

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.