KDE Sortie de Qt 4.6

Posté par . Modéré par Nÿco.
Tags :
49
1
déc.
2009
KDE
Qt 4.6, la bibliothèque C++ libre (GNU LGPL) et multi plates-formes vient de sortir. Comme à son habitude, à côté des optimisations plus ou moins importantes (voire spectaculaires en ce qui concerne QtScript), deux frameworks apparaissent dans le but de résoudre différents cas d'utilisations de cette bibliothèque multi-usages.

Symbian fait son entrée aux côtés des principales plate-formes supportées officiellement que sontLinux, Mac OS X, Windows et Windows CE. Symbian est un système d'exploitation pour smartphones détenu par Nokia (qui est également le propriétaire de Qt depuis janvier 2008). La prise en charge de Symbian se fait au travers du framework S60. Qt, c'est quoi?
Si un seul adjectif devait désigner Qt, c'est bien celui de vaste. Cette bibliothèque permet bien plus que de simplement développer des applications graphiques portables et permet également de faire (liste non exhaustive) :
  • du réseau (QtNetwork)
  • de la manipulation de documents XML (QtXml, QtXmlPatterns et QtSvg) ; un moteur de rendu HTML basé sur WebKit est également intégré (QtWebKit)
  • de la base de données relationnelle (QtSql) (avec un support natif des principales bases de données comme DB2, MySQL, Oracle, ODBC, PostgreSQL ou SQLite
  • du multimédia via Phonon (Phonon module) développé au sein de KDE
  • du script via QtScript (QtScript)
  • de la 3D via OpenGL (QtOpenGL)
  • de l'internationalisation via un outil pour les traducteurs : Qt Linguist (internationalization)
  • de la programmation concurrente via des processus légers (threads) ou un framework généraliste QtConcurrent (threads QtConcurrent)
  • des tests unitaires (QtTest)
  • de créer des interfaces graphiques pour les non-programmeurs via l'excellent Qt Designer (Designer manual)
  • ...
Un des points forts (mais pour certains c'est une critique) de Qt est le MOC, un préprocesseur de code C++ qui permet à l'aide de macros d'étendre le langage C++ en fournissant des mécanismes d'introspection et surtout une architecture de signaux (des évènements) et slots (des actions à réaliser suite à ces évènements) facilitant grandement le dialogue entre les différents objets C++ d'une application.

Qt ne se limite pas au C++ (bien que cela soit le langage de prédilection et le seul officiellement pris en charge depuis l'arrêt de QtJambi pour Java) car plusieurs bindings existent : Python, Java, C# et quelques autres moins avancés.

Cette version, elle apporte quoi de nouveau ?
Passons maintenant aux nouveautés de cette version :

Deux frameworks développés en interne depuis plusieurs mois et dont nous avons eu des aperçus via les blogs des développeurs de Qt apparaissent :
  • Animation, issu du projet Kinetic, il permet de créer des animations d'éléments graphiques et de jouer sur leurs propriétés
  • State Machine, qui utilise la sémantique des machines à état State Chart XML promue par le W3C. Ce framework simplifie la gestion des changements d'état (comme un bouton qui passe de non cliqué à cliqué) et l'action à réaliser qui suit.
Lorsque ces deux frameworks sont utilisés de concert, la réalisation d'animation est grandement simplifiée.

L'embarqué étant le secteur principal d'activité de Nokia, Qt se devait de fournir des outils pour gérer les évènements multi-points (comme sur l'iPhone pour donner une idée) et la gestuelle, c'est chose faite avec l'apparition des classes QTouchEvent et QGestureEvent.

La gestion d'XML est encore développée et après la gestion de XPath, XQuery et XSLT, vient s'ajouter dans cette version celui des Schema XML du W3C, permettant de valider un document XML. La manipulation d'éléments d'une page HTML est également facilitée via l'ajout de la classe QWebElement qui permet, entre autre, de sélectionner des éléments via les sélecteurs de CSS2.

Le développement du multimédia continue comme annoncé. Avec Qt 4.6, un nouveau module est ajouté, QtMultimedia, qui fournit un accès bas niveau au système audio, mais également vidéo via l'arrivée de plusieurs classes représentant des images d'un flux vidéo.

Concernant WebKit, la version est mise à jour depuis le tronc et un remplacement en règle est réalisé dans QtScript pour utiliser JavaScriptCore, l'interpréteur JavaScript de Webkit qui fait de la compilation juste à temps. Ce remplacement permet dans la majorité des cas une amélioration faramineuse (QtScript in 4.6). Toujours en ce qui concerne WebKit, une classe QWebInspector représentant l'outil d'analyse d'une page Web (l'équivalent de l'inspecteur DOM de Firefox) fait son apparition est permet d'intégrer cet outil dans une application Qt (mais son adaptation visuelle selon la plate-forme n'est pas encore au menu de cette version...).

Pour finir dans les nouveautés, une nouvelle classe de positionnement des widgets fait son apparition : QGraphicsAnchorLayout. Dédié aux éléments QGraphics, elle permet de les positionner relativement les un par rapport aux autres. Une présentation technique de cette classe est réalisée sur un Qt Blogs.

Comme j'ai bien évidemment dû oublier quelques nouveautés, une consultation de la page dédiée dans la documentation ne serait pas de trop pour les plus curieux d'entre vous.

Autour de Qt
Qt Creator, l'environnement de développement dédié à Qt, dont la première version est sortie en même temps que la version 4.5, est également mis à jour dans sa version 1.3. À côté de diverses améliorations, comme celle de la complétion et l'ajout d'un début de refactorisation, du support de Symbian, et de bien d'autres, s'en cache une qui pourrait intéresser nombre de lecteurs de LinuxFr : la traduction en français des outils Qt. Cette traduction, ainsi que celles en allemand, espagnol, italien, japonais, polonais, russe et slovène sont rendues possibles grâce à l'aide de la communauté qui a abattu un gros travail (Qt Créateur - Qt Creator is also in French). Ces contributions sont rendues possibles grâce à l'ouverture de plus en plus grande du développement de Qt, qui avant était fermé (même si l'on avait accès au source) et n'acceptait pas de contribution.

Concernant KDE dont le développement est intimement lié à celui de Qt, la prochaine version majeure, la 4.4, dont la sortie prévue est pour février 2010, utilisera cette version de Qt.

Le futur
Il est prévu en 2010 la livraison de plusieurs choses :

La plus importante est peut-être l'arrivée de Declarative UI et du langage de description QML. Ce sont la dernière partie du projet de recherche Kinetic (qui pour rappel contient les frameworks Animation et State Machine). L'utilisation de QML (dont un début de support est présent dans Qt Creator 1.3) se veut comme une nouvelle manière de décrire les interfaces graphiques (ce que fait actuellement les fichiers .ui de QtDesigner) et comment elles doivent se comporter (et c'est là la nouveauté). L'utilisation de QML a pour objectif de rendre la conception d'interfaces graphiques attrayantes (comprendre ici : contenant des effets de transitions entre les actions comme on en rencontres souvent dans de nombreuses interfaces utilisateurs de smartphones) plus facile. Un petit tour sur un des Qt Blogs explique plus en détail à quoi ressemble QML et ce que l'on peut en faire. Le projet KDE a rapidement vu l'intérêt de QML et a décidé de commencer à travailler sur son utilisation dans Plasma (le logiciel qui gère le bureau de KDE) et ses Plasmoids (des applications à "coller" où on veut sur le bureau).

A cela s'ajoute plusieurs cas d'utilisations spécifiques aux smartphones (mais qui dans certains cas sont pertinents pour le bureau) qui vont être pris en charge par Qt et connu sous le nom de Mobility Project. Ce sera notamment le cas de la géolocalisation, de la gestion de contacts, de l'envoi de messages (SMS, MMS, Jabber via XMPP et bien sûr courriel), etc. Un aperçu de l'API est disponible sous forme de Technology Preview et attend des commentaires.

Et, pour finir dans les grands projets dont la sortie est prévue en 2010 : la prise en charge de Maemo (la plate-forme de développement utilisée par certains appareils de Nokia) est prévue. Pour l'instant Maemo utilise GTK+, le portage de Qt sur cette plate-forme ne semble pas de bonne augure pour GTK+…

À plus long terme est prévu (en vrac et de manière non exhaustive) : une refonte du système de compilation, le support de SOAP (très utile pour les Web Services), une nouvelle génération de widgets (qui devrait prendre tout son sens avec l'utilisation de tous ce qui est issu du projet Kinetic), une nouvelle architecture pour la version Linux dédiée à l'embarqué (portant le doux nom de projet Lighthouse), une API 3D portable pour le bureau et l'embarqué (avec peut-être la fin de l'utilisation d'OpenGL directement...), etc.

Pour plus de détail sur les projets en cours, vous pouvez consulter une petite feuille de route.

Au final, je ne sais pas pour vous, mais je trouve le développement de Qt de plus en plus excitant !
  • # Une si bonne API

    Posté par . Évalué à  -10 .

    Pour un langage aussi pénible. Heureusement qu'il y a des bindings...
    • [^] # Re: Une si bonne API

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

      Les choses pénibles en C++ ne le sont plus trop avec Qt.

      Si tu penses aux makefiles, Qt propose QMake par exemple.

      Certes, il reste les erreurs à rallonge de gcc (mais ce n'est pas spécifique au C++), et la syntaxe qui n'est pas la plus fun en ce moment mais qui a l'immense avantage d'être compatible avec celle du C.

      Envoyé depuis mon lapin.

      • [^] # Re: Une si bonne API

        Posté par . Évalué à  2 .

        Certes, il reste les erreurs à rallonge de gcc (mais ce n'est pas spécifique au C++),

        Le C++ a pourtant sa "marque de fabrique" avec les problèmes liés aux templates. Ceci étant, il faut bien admettre que ce n'est pas avec Qt que ça pèse le plus.

        qui a l'immense avantage d'être compatible avec celle du C.

        Avantage, avantage, c'est vite dit. Pour ceux qui sont à l'aise en C et ne veulent pas se mettre à autre chose, pourquoi pas, mais ça devient rare.
        • [^] # Re: Une si bonne API

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

          Avantage, avantage, c'est vite dit. Pour ceux qui sont à l'aise en C et ne veulent pas se mettre à autre chose, pourquoi pas, mais ça devient rare.

          C'est un avantage, non pas pour ceux qui sont à l'aise avec le C, mais pour ceux qui ont un existant, des bibliothèques déjà construites.
          Car bon, le langage qui est le plus compatible avec les autres, ça reste le C quand même, il y a une tonne de binding d'autres langages pour des libs C, et pas l'inverse. (c'est quand même bizarre de voire que tous les langages "modernes" ont une interface pour accéder à des fonctions C...)
          • [^] # Re: Une si bonne API

            Posté par . Évalué à  5 .

            On parlait de la syntaxe du langage "source" là, pas de la compatibilité entre ABI. D'autant que le "pont" entre C et C++ est _un_peu_ à sens unique (va utiliser des bibliothèques C++ dans du code C, pour rire).

            Sans compter qu'en l'occurrence, un code C valide n'est pas forcément un code C++ valide (à la différence de l'Objective-C, si j'ai bonne mémoire). Donc la compatibilité niveau source, bon...

            Reste que je ne suis pas certain que le fait de pouvoir copier/coller un snippet en C dans un code en C++ suffise à justifier une syntaxe aussi lourde.
            • [^] # Re: Une si bonne API

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

              Il est possible d'inclure des header C directement depuis du code en C++
              (Je ne dis pas que ça justifie, je donne juste un avantage.)
      • [^] # Re: Une si bonne API

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

        Certes, il reste les erreurs à rallonge de gcc (mais ce n'est pas spécifique au C++)

        C++0x vise à simplifier les messages d'erreur des compilateurs.
        http://linuxfr.org/2009/07/24/25763.html

        la syntaxe qui n'est pas la plus fun en ce moment mais qui a l'immense avantage d'être compatible avec celle du C

        Contrairement à une idée reçue, C et C++ sont deux langages différents. Écrire des bouts de C en C++, c'est possible, mais c'est très crade (ex: mélanger printf(...) et cout<<...). D'ailleurs, quand on débute en C++, on a tendance à coder C plutôt qu'en C++ (genre préférer les structures aux objets).
        • [^] # Re: Une si bonne API

          Posté par . Évalué à  3 .

          C++0x vise à simplifier les messages d'erreur des compilateurs.

          Depuis qu'il a été décidé de supprimer les concepts de la prochaine version du C++, ce n'est plus le cas.


          Étienne
          • [^] # Re: Une si bonne API

            Posté par . Évalué à  3 .

            Et c'est bien dommage.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Une si bonne API

          Posté par . Évalué à  4 .

          « D'ailleurs, quand on débute en C++, on a tendance à coder C plutôt qu'en C++ (genre préférer les structures aux objets). »

          Qui est ce « on » ? J'ai appris C et C++ la même année (6 mois de C globalement, 2-3 mois de C++, mais juste la partie « C avec classes », donc pas de templates, pas d'utilisation de namespaces, etc). Dès le départ, on nous avait fait utiliser cout. Alors oui, il s'agissait de cours d'IUT, et oui, le fait de choisir C++ plutôt que Java n'était sans doute pas anodin, mais dès le départ, pas mal de choses étaient claires.

          Les gens qui font « du C » en C++ ce sont des gens qui font du procédural dans un langage orienté objet, selon moi (donc utilisation de méthodes de classes ou de fonctions, utilisation de codes de retour plutôt qu'utiliser les exception quand clairement ça se justifierait, etc). Et ça par contre, je l'ai déjà vu faire, même (surtout ?) avec des gens qui avaient 20 ans d'expérience.
        • [^] # Re: Une si bonne API

          Posté par . Évalué à  3 .

          Ca c'est *très* discutable!
          Personellement je trouve les 'cout <<' du C++ pourri et utilise a la place les printf, ce qui est très rependu..



          • [^] # Re: Une si bonne API

            Posté par . Évalué à  5 .

            > Personellement je trouve les 'cout <<' du C++ pourri et utilise a la place les printf, ce qui est très rependu..

            ça montre surtout que ton niveau en C++ n'est pas très bon. Les flux C++ offrent par rapport aux entrées/sorties C la sûreté de typage, moins d'erreurs possibles (avec les % notamment), facilement extensibles avec les types utilisateurs (suffit de redéfinir les opérateurs, en C rien de comparable, bien que la GNU libc offre quelques crochets).
            Encore printf ça peut passer, mais des horreurs comme scanf non.
            • [^] # Re: Une si bonne API

              Posté par . Évalué à  4 .

              Quand il faut afficher des choses à l'utilisateur, je m'abstiens d'utiliser "std::cout << " pour une seule raison : les traductions...

              std::cout << "j'ai " << nbChiens << " chiens et " << nbCats << " chats." << std::end

              vs

              printf("J'ai %d chiens et %d chats\n", nbChients, nbChats);

              En revanche, il y a plein de cas où c'est super pratique, genre les fichiers de log.
              • [^] # Re: Une si bonne API

                Posté par . Évalué à  3 .

                C'est effectivement un des cas où les flux C++ sont pas très bien adaptés.
                Tu as d'autres alternatives pour les chaines formatées comme la classe autosprintf fournie avec gettext, ou bien Boost.Format qui gérent en interne leur propre flux. Best of both worlds comme on dit.
                Pour revenir à Qt, la solution recommandée c'est d'utiliser la méthode arg de QString qui offre la souplesse et une sûreté de typage comparable à celle de Boost.Format.

                Par ailleurs, l'utilisation de std::endl au lieu de '\n', n'est pas forcément recommandé, std::endl force le flush du buffer d'écriture, à utiliser avec modération.
              • [^] # Re: Une si bonne API

                Posté par . Évalué à  2 .

                Surtout si tu as 0 ou même 1 seul animales pour une ou plusieurs espèce...
            • [^] # Re: Une si bonne API

              Posté par . Évalué à  4 .

              Attention je n'ai pas dit que le printf C était parfait, juste qu'il avait une syntaxe bien supérieure a celle de 'cout <<' en C++.

              Je ne suis pas le seul a le penser: le concepteur de D (un langage 'réinventant' le C++) qui est un expert C++ (il a codé un compilateur C++) a fait pour D 'writef' qui est une version améliorée de printf, PAS 'cout <<'..
              • [^] # Re: Une si bonne API

                Posté par . Évalué à  3 .

                > juste qu'il avait une syntaxe bien supérieure a celle de 'cout <<' en C++.
                Elle est surtout "defective by design".
                Les chaines C, printf, etc ... tout ça c'était l'état de l'art dans les années 70/80, depuis, les std::string et les flux C++ sont arrivés. Certes, std::string et les flux C++ ont montrés leurs limites, mais Boost (qui porte bien son nom) permet de pallier à bon nombre de ces défauts.
                Pour des entrées/sorties console, tu as de moins en moins de raisons d'utiliser les antiquités hérités du C.

                Quant aux toolkits modernes, ils offrent des type string adaptés (support d'unicode, capacité de formatage robuste, i18n, etc ...), souvent interopérables avec la SL (je pense à QString, mais également glib::ustring ou bien wxString).


                > le concepteur de D (un langage 'réinventant' le C++) qui est un expert C++ (il a codé un compilateur C++) a fait pour D 'writef' qui est une version améliorée de printf, PAS 'cout <<'..

                writef n'a récupéré de printf que la syntaxe de formatage et un nom vaguement similaire. writef est type safe, comme tu le dis Walter Bright a une grande expérience dans l'implémentation de langage de programmation. Ça reste néanmoins plus proche de ce qui se fait en C++ qu'en C (même si personnellement, je trouve que ça s'inspire plus de l'équivalent Java en beaucoup moins bordélique).
                Enfin, les entrées/sorties fournies par Tango la bibliothèque standard alternative sont nettement supérieures (ironiquement, l'équivalent de writef dans Tango s'appelle Cout ...) avec des capacités de formatage proches de ce qui fait actuellement (Boost.Format, QString, python, C#, etc ...). Et la bibliothèque standard la plus utilisée est Tango et non pas Phobos, celle qui offre des entrées/sorties le plus proche du C++.
                • [^] # Re: Une si bonne API

                  Posté par . Évalué à  2 .

                  writef n'a récupéré de printf que la syntaxe de formatage et un nom vaguement similaire.

                  Ça tombe bien, depuis le début du thread on parle de la syntaxe de printf, et non de son implémentation/conception.
                  • [^] # Re: Une si bonne API

                    Posté par . Évalué à  2 .

                    Le sujet d'origine c'est "cout c'est pourri, printf saimieu" ou autrement dit "pourquoi utiliser les flux C++ et non pas les entrées/sorties C en C++".
                    Personellement je trouve les 'cout <<' du C++ pourri et utilise a la place les printf

                    > Ça tombe bien, depuis le début du thread on parle de la syntaxe de printf, et non de son implémentation/conception.
                    Et juste en dessous, je précise que la bibliothèque D standard la plus utilisé (Tango) offre des entrées/sorties inspirées du C++ avec des capacités de formatage modernes comme ce qui se fait aujourd'hui.
                    La syntaxe printf est certes pratique mais dépassée, les syntaxes modernes permettent de réutiliser plusieurs fois le même argument, de modifier l'ordre des arguments etc ...


                    Si ça te chante, tu peux très bien faire ta propre fonction improved_printf qui gère son propre flux en interne. Les entrées/sorties C++ sont un poil plus bas-niveau que leur homologue C mais en contrepartie, elles sont plus sûres et extensibles. L'absence de fonctionnalités plus haut niveau dans le standard est regrettable mais ce n'est pas une raison valable pour préférer printf. Le problème des bibliothèques standards, c'est que tu ne peux pas tout inclure dedans et il vaut mieux réfléchir plusieurs fois avant d'inclure quelque chose dedans.
                    Et c'est oublier des extensions de la bibliothèque standard comme Boost (ou même POCO), ou bien ce que propose n'importe quel toolkit moderne comme Qt.
                    • [^] # Re: Une si bonne API

                      Posté par . Évalué à  2 .

                      La syntaxe printf est certes pratique mais dépassée, les syntaxes modernes permettent de réutiliser plusieurs fois le même argument, de modifier l'ordre des arguments etc ...

                      certaines implémentation de printf le permettent maintenant:
                      printf("%1$d %1$d", 3);

                      et tu peux mettre l'ordre que tu veux
                      printf("%3$d %1$d %2%d", 4, 8, 9);

                      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

                      • [^] # Re: Une si bonne API

                        Posté par . Évalué à  4 .

                        On voit quand même que faire le formatage dans la chaine de format n'est pas la panacée et que ça devient rapidement des incantations chamaniques. Je n'ai pas trouvé comment faire l'équivalent de :
                        int num=12, width=8;
                        char fillChar='#';
                        std::cout << std::setfill(fillChar) << std::setw(width) << num;


                        Alors certes c'est parfois un peu verbeux lorsqu'il n'y a aucun formatage à faire mais dès qu'on veut faire la moindre petite chose c'est à la fois puissant, expressif et beaucoup plus souple qu'une chaîne de format.
                        • [^] # Re: Une si bonne API

                          Posté par . Évalué à  2 .

                          printf("%#8d", 12)
                          • [^] # Re: Une si bonne API

                            Posté par . Évalué à  3 .

                            D'une part cela ne marche pas, d'autre part le # et le 8 ne sont pas dans des variables.

                            Étienne
                        • [^] # Re: Une si bonne API

                          Posté par . Évalué à  3 .

                          > mais dès qu'on veut faire la moindre petite chose c'est à la fois puissant, expressif et beaucoup plus souple qu'une chaîne de format.

                          Bon, quitte à entrer dans le troll, allons-y franchement.

                          Comment fais-tu :
                          * pour utiliser gettext avec ce magnifique système ? Les défenseurs de C++ ont toujours tendance à considérer ce point comme négligeable et à l’occulter ; en pratique, il ne l’est absolument pas (négligeable)
                          * un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
                          • [^] # Re: Une si bonne API

                            Posté par . Évalué à  2 .


                            * pour utiliser gettext avec ce magnifique système ? Les défenseurs de C++ ont toujours tendance à considérer ce point comme négligeable et à l’occulter ; en pratique, il ne l’est absolument pas (négligeable)


                            On peut utiliser boost format (ou d'autres, loki safeformat, fastformat, ...) qui s'intègrent très bien avec gettext tout en étant typesafe.

                            * un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
                            Sur ce point on a une bien plus grande souplesse avec les flux de la STL qui sépare bien la partie formatage de la partie lecture/ecriture à travers les streambuf. Ce qui permet de faire des choses comme :
                            * écrire dans plusieurs fichiers simultanément
                            * fournir un pourcentage de progression au fur et à mesure de la lecture d'un fichier
                            * lire depuis/vers un buffer,
                            * lire depuis/vers une socket
                            * ...

                            Il suffit pour cela de fournir son propre streambuf. On peut pour cela s'aider de boost::iostreams qui simplifie bien les choses.

                            Pour simplement faire un tee, on peut aussi faire comme en C

                            On peut trouver, et à raison, que la STL est un peu complexe à ce niveau, mais on a une souplesse indéniable.

                            Étienne
                            • [^] # Re: Une si bonne API

                              Posté par . Évalué à  3 .

                              > On peut utiliser boost format (ou d'autres, loki safeformat, fastformat, ...) qui s'intègrent très bien avec gettext tout en étant typesafe.
                              On parle des librairies standard, là. À ce niveau, je peux te dire que l’implémentation de GCC est capable de vérifier les types (certes, il n’émet que des warnings)

                              > Il suffit pour cela de fournir son propre streambuf
                              Si je t’ai fourni un problème concret, c’est bien parce que le niveau stratosphérique ne m’intéresse pas. Je sais pertinemment que tu peux fournir tes propres classes pour les IO. La question implicite était : sur un problème simple, peux-tu me faire là, maintenant, en 5 minutes, une solution simple ? Ce que je voulais savoir, c’était la faisabilité pratique de la chose.
                          • [^] # Re: Une si bonne API

                            Posté par . Évalué à  2 .

                            > pour utiliser gettext avec ce magnifique système ?
                            Comme je l'ai précisé plus haut, les flux C++ sont des briques bas-niveau, rien ne t'interdit de construire un système de formattage par dessus. C'est ce que fait Boost.Format (avec des capacités supérieures à ce que propose C89/99), ou bien la classe autosprintf fourni par gettext qui en interne gère un flux C++. Tu bénéficies de la sûreté de typage tout en gardant les avantages du formatage.

                            > un équivalent de tee, qui sorte ta chaine à la fois sur cout et sur un fichier de log ?
                            À ce niveau là, la bibliothèque standard C et les flux C++ sont à égalité.
                            Certes le système des flux C++ est plus complexe à assimiler, mais une fois qu'on a compris, ça roule (Stroustrup a même fait un joli schéma). Pour ton exemple de tee, ça n'a rien de compliqué, il suffit de réécrire une classe héritant de std::streambuf qui redirige l'entrée vers plusieurs objets std::streambuf, et pour faire la redirection, tu utilises la méthode rdbuf pour faire la substitution. Tu peux écrire une classe héritant d'ostream pour avoir une interface plus agréable.
                            Boost.Iostreams facilite l'écriture de buffers, flux et filtres et fournit une collection d'objets prêt à l'emploi dont un tee.

                            ofstream ofs("mon_fichier.log");
                            tee_device<ostream, ofstream> teeDevice(cout, ofs);
                            stream teeStream(teeDevice);
                            teeStream << "comment faire un tee avec Boost, ne pas oublier de flusher le buffer !"<<std::endl;
                            teeStream.close();

                            Vachement compliqué à utiliser, non ?


                            Cette discussion confirme qu'une bonne partie des développeurs C++ ont une connaissance très partielle du langage y compris des bases (on parle quand même des entrées/sorties !).
                            Ça ne m'étonne guère, C++ en soi est ardu d'apprentissage, la plupart des formations enseigne un dialecte déprécié (le fameux C avec classes), les implémentations conformes à la norme se sont fait attendre longtemps etc...
                            Mais avant d'accuser C++ de tout les maux, faudrait peut-être l'apprendre correctement avant et choisir les bons outils. Aujourd'hui, un développeur C++ digne de ce nom doit être familier avec Boost ou du moins une bonne partie de Boost
                            • [^] # Re: Une si bonne API

                              Posté par . Évalué à  2 .

                              > Vachement compliqué à utiliser, non ?
                              Clairement, non, et je m’en doutais.
                              Ce qui me laisse plus dubitatif au niveau simplicité, c’est l’implémentation de tee_device.
                              (malheureusement, mon proxy http étant tombé (probablement pour le week-end), je n’ai plus accès qu’à https, un exemple ici serait le bienvenu, même simplifié ; je n’ai pas boost installé sur ma machine)

                              > Comme je l'ai précisé plus haut, les flux C++ sont des briques bas-niveau, rien ne t'interdit de construire un système de formattage par dessus.
                              Et comme dit également plus haut, ce sont les méthodes standard de la librairie standard qui nous intéressent. Si la librairie standard n’est même pas fichue de faire des IO adaptables simplement, autant ne pas s’embêter à en fournir une.

                              > Cette discussion confirme qu'une bonne partie des développeurs C++ ont une connaissance très partielle du langage y compris des bases (on parle quand même des entrées/sorties !)
                              1. Je ne suis pas un développeur C++, juste un curieux, curieux de comprendre comment on peut appeler « supérieur » un système d’IO qui nécessite de connaître en profondeur les subtilités d’un langage réputé très complexe (héritage de classes templatées, il ne me semble pas que ce soit le chapitre 1 d’un bouquin de C++…) pour faire quelque chose d’aussi simple qu’une fonction tee() ou gettext() (utiliser une librairie externe comme boost n’est pas une réponse, on discutait des librairies standard)
                              2. Est-ce la faute du langage (j’inclus dans langage la librairie standard, mais pas les librairies externes : le dénominateur commun de ce que je peux faire avec un gcc, icc et visual studio fraichement installés) ou du développeur si la base (les IO) de la base (la librairie standard) n’est pas simplement assimilable ?
                              • [^] # Re: Une si bonne API

                                Posté par . Évalué à  2 .

                                > Ce qui me laisse plus dubitatif au niveau simplicité, c’est l’implémentation de tee_device.
                                Voici comment faire sans bibliothèque extérieure.

                                #include
                                #include
                                #include

                                class TeeBuf: public std::streambuf
                                {
                                public:
                                TeeBuf(std::streambuf * buf1, std::streambuf * buf2): buf1(buf1), buf2(buf2) {}
                                private:
                                int overflow(int c)
                                {
                                if (c == EOF) {
                                return !EOF;
                                } else {
                                return (EOF == buf1->sputc(c)) || (EOF == buf2->sputc(c)) ? EOF : c;
                                }
                                }
                                int sync()
                                {
                                return (0 == buf1->pubsync()) && (0 == buf2->pubsync()) ? 0 : -1;
                                }
                                private:
                                std::streambuf * buf1;
                                std::streambuf * buf2;
                                };

                                class TeeStream : public std::ostream
                                {
                                public:
                                TeeStream(std::ostream &o1, std::ostream &o2) : std::ostream(&buf), buf(o1.rdbuf(), o2.rdbuf()) {}
                                private:
                                TeeBuf buf;
                                };

                                int main()
                                {
                                using std::cout;
                                std::ofstream ofs("mon_fichier.txt");
                                /* avec TeeBuf */
                                std::streambuf *sortieLog = ofs.rdbuf();
                                std::streambuf *sortieStandard = cout.rdbuf();
                                TeeBuf *teeBuf = new TeeBuf(sortieStandard, sortieLog);
                                std::streambuf *oldBuf = cout.rdbuf(teeBuf);
                                cout<<"hello ";
                                cout.rdbuf(oldBuf);
                                /* avec TeeStream c'est un poil plus agréable */
                                TeeStream tee(cout, ofs);
                                tee<<"world!"<<std::endl;

                                ofs.close();
                                return 0;
                                }


                                > Et comme dit également plus haut, ce sont les méthodes standard de la librairie standard qui nous intéressent. Si la librairie standard n’est même pas fichue de faire des IO adaptables simplement, autant ne pas s’embêter à en fournir une.

                                Tu soulèves un dilemme qui touche tout les concepteurs de langages de programmation, quel doit être le contenu de la bibliothèque standard ?
                                C++ a fait le choix de fournir un système d'entrée/sortie souple et puissant (pas super compliqué) mais très rugueux, c'est un choix parmi d'autre.

                                > Je ne suis pas un développeur C++, juste un curieux, curieux de comprendre comment on peut appeler « supérieur » un système d’IO qui nécessite de connaître en profondeur les subtilités d’un langage réputé très complexe

                                Il est pas si complexe que ça, les IO Java sont bien plus tordues que ça à mon avis.
                                Si tu te limites à de l'affichage console, l'écriture dans des fichiers, c'est pas plus compliqué qu'avec les entrées/sorties C. Là, on s'attaque à un problème bien spécifique: i18n.
                                On peut s'attaquer aux entrées/sorties sans forcément devoir s'occuper des détails, std::string est également une spécialisation d'une classe templaté et ça ne pose pas de problèmes.

                                Enfin, si c'est pour faire du C en C++ sans utiliser les fonctionnalités avancés (stdio, pas de RAII, pas d'exception, pas de templates etc ..), autant faire du C.

                                > Est-ce la faute du langage ou du développeur si la base (les IO) de la base (la librairie standard) n’est pas simplement assimilable ?

                                Je dirais les deux, d'une part, C++ est un langage assez rugueux, de l'autre, C++ est très mal enseigné ce qui n'aide pas. Les concepteurs du langage en sont conscients (C++0x va dans ce sens) et cherchent à simplifier le langage.
                                C++ n'est clairement pas un langage adapté à des débutants en programmation, même si le dernier bouquin de Stroustrup (adaptation de son cours à des 1ères années de fac) démontre que c'est possible (une traduction est en cours aux éditions Pearson fr).
                                Dans le bouquin, il enseigne un style de programmation C++ moderne et n'aborde le sous-ensemble C du C++ que dans le dernier chapitre tout en restant accessible à tous.

                                Que ce soit en C ou en C++, si tu te limites à la bibliothèque standard, tu risques pas d'aller bien loin. Boost est aussi essentiel à un développeur C++, que Posix l'est à un développeur C.
                        • [^] # Re: Une si bonne API

                          Posté par . Évalué à  2 .

                          J'ai bien regardé tout partout, et s'il est facile de spécifier un remplissage dynamique par des espaces ( printf("%*d\n", width, num); ), il n'y a effectivement pas de fonction disponible dans la bibliothèque de base du C pour faire directement ce que tu veux faire (remplir width fois la chaîne avec fillChar).

                          Suivant que tu veux faire une « surcharge » de printf ou pas (genre écrire un fillprintf(const char *format, ...)), faire ce que tu veux en C est soit loin d'être trivial (pour rajouter une option à analyser dans la chaîne, il faut se retaper toute la chaîne globalement, et tout analyser), ou bien tu fais une fonction du genre fill_string(const char *format, const size_t pos, const char filler, ...);
                          Tout dépend.

                          Je suis d'accord pour dire que les streams C++ ne sont pas si pourris que ça. Par contre, leur apprentissage n'est pas évident selon moi.
  • # Dépêche de qualité

    Posté par . Évalué à  10 .

    Merci pour cette dépêche monstrueusement bien faîte !
    • [^] # Re: Dépêche de qualité

      Posté par . Évalué à  10 .

      Merci bien. J'espère ne pas avoir raconté trop de bêtises sur des trucs que je n'ai pu testés où sur lesquels je ne me suis pas particulièrement penchés.
    • [^] # Re: Dépêche de qualité

      Posté par . Évalué à  10 .

      J'abonde : la dépêche est limpide, agréable à lire et apporte plein d'infos intéressantes.
      Les dépêches de cette qualité sont rares.

      BeOS le faisait il y a 15 ans !

  • # Multitouch

    Posté par . Évalué à  5 .

    Bonsoir,

    Au niveau du multitouch il semblerait que les développeurs ne l'utilisent que sur les ports windows et mac (à travers les ports de KDE4) à cause du manque de solution sous linux...

    Qu'en est-il du support de cette technologie au sein de X? Quelles sont les échéances? Un an? Six mois? Y a-t-il des problèmes particuliers qui empêchent l'émergence d'une solution (brevets...) ou bien « seulement » un manque de moyen en développement?

    Je trouve dommage que Qt qui se veut multiplateforme soit tronqué d'un de ses plus grands apports en terme d'ergonomie utilisateur pour sa version linux (sachant que KDE sous linux pourrait tirer parti de cette technologie assez rapidement par exemple).
    • [^] # Re: Multitouch

      Posté par . Évalué à  3 .

      La doc de QTouchEvent ( http://doc.trolltech.com/4.6/qtouchevent.html ) ne parlent pas de limitations particulières selon les plate-forme.

      Maintenant, je n'ai pas tester cette fonctionnalité...
    • [^] # Re: Multitouch

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

      Il me semblait que la dernière version de X.org gérait le muli-touch (on en parle notamment ici: https://linuxfr.org//2009/10/14/26025.html ). Mais, ils n'ont peut-être pas eu le temps de l'intégrer pour cette version.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Multitouch

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

      Il semble selon un récent post sur le planet kde que un début de support du multitouch arrive dans kde 4.4 ...
      Malheureusement, cette partie multitouch ne repose pas sur MPX, ils utilisaient un événement avec des positions différentes plutôt que plusieurs évènements.

      La personne semblait dire qu'un support de MPX n'allait pas tarder...
  • # La naissance du port Symbian

    Posté par . Évalué à  6 .

    Un article très intéressant sur la naissance du port et l'avancement du projet mois par mois par un ingénieur de Nokia/Qt.
    http://labs.trolltech.com/blogs/2009/12/01/a-brief-history-o(...)
  • # Oo !

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

    J'y crois pas, ca me donne envie de passer sous KDE pour faire des applis Qt (même si j'aime bien mon Ubuntu avec GTK ;) ).

    Après avoir lu les pages des liens, je suis bluffé ! Je passe dès ce soir à Archlinux KDE !

    Et le coup final qui ferait baver n'importe quel developpeur : http://qt.nokia.com/developer/qt-roadmap

    « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

    • [^] # Re: Oo !

      Posté par . Évalué à  9 .

      Pas besoin de passer sous KDE pour développer en Qt, les applications Qt s'intègrent très bien à un environnement GNOME.
      • [^] # Re: Oo !

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

        "Très bien"

        Tout est relatif, déjà ca te fait une tonne de libs en plus, il y a quelques bugs (la zone d'entrée de texte qui devient noire quand on écrit, les notifications, ...), graphiquement c'est pas super bien adapté.

        « En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll

        • [^] # Re: Oo !

          Posté par . Évalué à  8 .

          > une tonne de libs en plus
          C'est relatif, en embarqué, on se limitera souvent à un seul toolkit graphique (et encore, c'est de moins en moins le cas), sur un desktop, c'est nettement rare.
          Qt n'est pas plus lourd que Gtk+, wxWidgets & cie, et en terme de dépendances, rien d'extravaguant par rapport à un GNOME vanilla.

          > il y a quelques bugs (la zone d'entrée de texte qui devient noire quand on écrit, les notifications, ...)
          Jamais rencontré et pas recensé chez Fedora.
          https://admin.fedoraproject.org/pkgdb/packages/bugs/qt
          Le seul bogue graphique était un affichage bogué dans qtdemo-qt4 lié au pilote Intel, et il a été corrigé dans Qt 4.6.

          > graphiquement c'est pas super bien adapté.
          Avec QGtkStyle, tu remarques à peine la différence graphiquement.
          Personnellement, je trouve que les applications s'intègrent mieux dans un environnement GNOME que les applications wxWidgets qui pourtant s'appuie sur Gtk+ sous GNU/Linux.
        • [^] # Re: Oo !

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

          Tu confonds peut être KDE et Qt.

          une tonne de libs en plus ?
          Non, juste une: Qt (ok, elle est subdivisée en quelque modules, mais c'est loin de la diversité de libs qu'il te faut si tu fait du gtk, du gnome, ou du kde)

          Quelques bugs ?
          Peut être, mais c'est comme partout, et puis si il y a des bug, il faut les rapporter et ils seront sans doute corrigé.

          graphiquement c'est pas super bien adapté ?
          S'il y a peut être quelque petite détails qui diffèrent avec les appli gtk+, dans l'ensemble, je ne pense pas qu'on puisse dire que c'est pas adapté.

          Là encore, pas confondre applications KDE et applications Qt.
  • # Qt Creator

    Posté par . Évalué à  4 .

    Juste un petit retour.

    Il y a environ deux semaines j'ai commencé à développer un petit truc pour mes parents, j'avais choisi Qt mais je développais avec Vim + Konsole.
    Finalement j'ai décidé de tester Qt Creator, et je n'utilise que ça maintenant. C'est vraiment un très bon IDE, super simple, la complétion est bien foutue, les erreurs de compilation (la fenêtre nous permet de cliquer sur l'erreur, ce qui ouvre directement le fichier concerné à la bonne ligne), la coloration syntaxique bien faite.
    J'ai retrouvé le même feeling de simplicité qu'à l'époque où je bossais sur du Java avec Eclipse, chose que je n'avais pas retrouvé avec Kdevelop quand je l'avais testé.

    Bon, le support de CMake c'est pas encore ça, je suis obligé de relancer moi même cmake dans le répertoire "build", sinon QtCreator ne voit pas les nouveaux fichiers ajoutés.
    Autre chose qui serait bien, ça serait d'avoir la doc d'une méthode quand on utilise la complétion (j'ai pas l'impression que c'est disponible).

    Bref, c'est vraiment du bon.
    • [^] # Re: Qt Creator

      Posté par . Évalué à  2 .

      > ça serait d'avoir la doc d'une méthode quand on utilise la complétion
      Tu as accès à l'aide contextuelle via le raccourci F1 et l'aide s'affiche dans un panneau à droite.

      QtCreator est un excellent IDE pour travailler avec Qt, simple et sans fioritures, perso, je travaille avec une version Git régulièrement actualisée (ça me permet d'avoir le support de mercurial entre autre).
      FakeVim permet d'avoir un éditeur décent presque entièrement pilotable au clavier, mais un FakeEmacs me ferait bien plaisir.
      • [^] # Re: Qt Creator

        Posté par . Évalué à  9 .

        mais un FakeEmacs me ferait bien plaisir.

        Rassures-toi, avec le multitouch ça ne devrait plus trop tarder...
  • # c++ ??

    Posté par . Évalué à  -10 .

    Et après on s'étonne des bugs dans les applications.

    Qt46Ada, sinon rien.
  • # Petite correction

    Posté par . Évalué à  6 .

    Qt ne se limite pas au C++ (bien que cela soit le langage de prédilection et le seul officiellement pris en charge depuis l'arrêt de QtJambi pour Java) car plusieurs bindings existent : Python, Java, C# et quelques autres moins avancés.

    Nokia a lance pyside pour faire un binding python. Je pense que l'on peut donc dire que Nokia (et donc Qt) prend en charge officiellement python.

    http://www.pyside.org/

    Il existe aussi le tres bon bindings de riverbank qui rend le developpement d'applis Qt bien pratique.

    http://www.riverbankcomputing.co.uk/news
    • [^] # Re: Petite correction

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

      PySide est un projet de recherche qui en est à ses début (version pré alpha) créé par un institut de recherche (dépendant de Nokia)

      Rien de supporté officiellement encore donc.

      PyQt par contre est supporté par son créateur (mais pas par Nokia) et est parfaitement fonctionnel.
      • [^] # Re: Petite correction

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

        La principale différence est la licence. Contrairement à Qt, PyQt est sous licence GPL, et son auteur vend une version commerciale (comme le faisait Qt il y a quelques temps). PySide est diffusé sous licence LGPL, comme Qt.

        PyQt utilise un outil de binding spécifique à Qt, « SIP ». C'est un genre d'extension au C++ qui sert à générer un binding pour l'API C de Python. C'est assez spécial et ça n'est utilisé par aucun autre projet. Ça ne facilite pas les contributions, ni le debug :-/

        Je ne sais pas ce que PySide utilise pour écrire le binding.
        • [^] # Re: Petite correction

          Posté par . Évalué à  3 .

          > Je ne sais pas ce que PySide utilise pour écrire le binding.
          Un fork de QtScriptGenerator basé sur Boost.Python (d'où l'absence de support de Python 3 contrairement à PyQt), un plugin permet également de générer directement du code utilisant l'API CPython.
          http://www.pyside.org/home-binding/binding-generator/

          Sur la mailing-list, il avait été évoqué de remplacer Boost.Python par smoke le générateur de bindings de KDE.
          • [^] # Re: Petite correction

            Posté par . Évalué à  4 .

            Sur la mailing-list, il avait été évoqué de remplacer Boost.Python par smoke le générateur de bindings de KDE.

            Je pense que cela serait une bonne idee. Boost.Python c'est vraiment pas la joie a utiliser et comme 90% des trucs boost que j'ai tente d'utilisre "Oh mon dieu la doc"... Non franchement c'est une horreur la doc de boost. Il y a un enorme effort a faire de ce cote la.
  • # Bravo aux développeurs Qt

    Posté par . Évalué à  2 .

    Après un rapide survol de la documentation, j'ai l'impression que Qt permet de faire de nombreuses choses équivalentes à la future Technical Report 1.
    Je me trompe, ou bien seront elles complémentaires ? Mon sentiment est que TR1 est une extension mort née..
    • [^] # Re: Bravo aux développeurs Qt

      Posté par . Évalué à  3 .

      tr1, C++1x et co, ça ne sort jamais...
    • [^] # Re: Bravo aux développeurs Qt

      Posté par . Évalué à  4 .

      > j'ai l'impression que Qt permet de faire de nombreuses choses équivalentes à la future Technical Report 1.
      Qt duplique bon nombre de fonctionnalités de la bibliothèque standard C++ (QString/std::string, Tulip/STL, etc ...) pour diverses raisons notamment historiques. Qt précéde la norme C++98 et il a fallu attendre longtemps avant que la plupart des compilateurs aient un support décent de celle-ci. Sur certaines plateformes embarqués, pas d'exceptions, pas de RTTI, pas de STL !
      Je ne comprends pas pourquoi tu dis *future* TR1 ? TR1 est un ensemble de propositions d'extensions de la SL en prévision de C++0x (la plupart étant basées sur Boost) qui dans l'ensemble a été assez rapidement adopté par les vendeurs et Boost fournit même une implémentation multiplateforme.

      TR1 n'est pas mort-né, ça a plutôt bien marché (on peut pas en dire autant de TR2) et c'est inclus dans C++0x.
      • [^] # Re: Bravo aux développeurs Qt

        Posté par . Évalué à  2 .

        Je ne crois pas qu'à ce jour, la gnu libstdc++ l'implémente complètement (les regex entre autres n'y sont pas). Pour les autres implémentations,
        je ne peux pas dire, je ne les connais pas. Enfin, cette librairie ira de paire avec la nouvelle norme C++ qui n'est toujours pas là..
        Ce sont ces 2 points qui me font employer le mot future.
        • [^] # Re: Bravo aux développeurs Qt

          Posté par . Évalué à  4 .

          Certes, manque à l'appel les regex et un bout de la partie compatibilité avec C99. Mais tu as toujours en fallback l'implémentation Boost. Si tu regardes bien, tu trouveras quelques bouts de la norme C++98/03 qui ne sont pas implémentés dans libstdc++. Quant aux autres implémentations, Visual Studio/C++ Builder se base sur celle de Dinkumware qui est complète (enfin, ils ne livrent pas tout dans le cas de VS). Pour le compilo Sun, ils sont complétement à la ramasse.
          La plupart des développeurs C++ ont bien accueilli TR1 et certains s'en servent quotidiennement.

          > Enfin, cette librairie ira de paire avec la nouvelle norme C++ qui n'est toujours pas là..
          TR1 est avant tout une extension de C++03 qui pour la plupart ne nécessite aucun changement au niveau du compilateur. L'espace de nom std::tr1 ne disparaitra pas avec l'arrivée de C++0x (même si le contenu sera également disponible dans std)
      • [^] # Re: Bravo aux développeurs Qt

        Posté par . Évalué à  4 .

        oui enfin QString et std::string c'est un peu la différence entre un vélo et une moto...
        il manque 2/3 trucs dans std::string (heureusement boost est la)
        ( sprintf, split, number, trimmed, simplified, section...)

        Y a aussi la QStringList avec ses filtre en expression rationnelles, permettant de retourner la liste des QString correspondant :D.

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

  • # Catégorie.

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

    La dépêche montre le Logo de KDE, ce qui pourrait porter à confusion.
    KDE et Qt sont deux projets différents. Même si l'un utilise l'autre, Qt ne se limite pas du tout à KDE

    Je m'explique :
    Qt se veux multiplatforme. Une application écrite avec Qt fonctionne et s'intègre dans n'importe quel environement ; KDE, Gnome, Windows, Mac, Maemo, WindowsCE, Symbian, ....

    Par contre, KDE est un environement homogène d'applications qui défini ses propre règles d'interface. Une application KDE, même si elle fonctionnera sous windows, mac, ou gnome, ne s'y intégrera pas vraiment, car ce n'est pas l'objectif de KDE (même si cela change un peu). Une application KDE utilisera des bibliothèques qui chargeront des démons KDE et aura un look&feel KDE.

    KDE utilise Qt pour ses autres qualités (Bonne API, facilité de programmation, documentation, ...). Mais les projets sont complétement différents et ne doivent pas être confondus.

    À lire certain commentaires, j'ai l'impression que certains confondent, je devais préciser.
  • # Fichtre !

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

    Ca en fait des choses dans cette "bibliothèque".

    A quand un QtKernel pour booter directement en Qt ? :-)

    Blague à part, il me parait intéressant d'avoir un ensemble cohérent de bibliothèques qui adresses des problématiques aussi variées que le réseau, XML, les IHM... Mais ces différentes bibliothèques sont-elles réellement utilisables indépendamment les unes des autres ?

    Par exemple, mon travail quasi quotidien consiste à développer des systèmes distribués avec des serveurs et des IHM. Donc, dans les serveurs, point d'IHM :-)
    • [^] # Re: Fichtre !

      Posté par . Évalué à  7 .

      Oui, comme décrit dans la dépêche, Qt est scindé en modules, et chaque module peut être utilisé ou non par un projet.

      Le seul module obligatoire (et automatiquement "activé") pour coder une appli Qt est QtCore. Pour utiliser d'autres modules, il faut les déclarer dans le fichier de configuration du projet (*.pro).

      C'est propre et bien géré de ce côté. ;-)
    • [^] # Re: Fichtre !

      Posté par . Évalué à  6 .


      A quand un QtKernel pour booter directement en Qt ? :-)


      Et pourquoi pas un gestionnaire de paquets tant que tu y es ?
      ....
      http://linuxfr.org/~steckdenis/29087.html
  • # Maemo

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

    C'est bizarre, dans la news, on parle d'un support future de Maemo, tandis que d'après http://qt.nokia.com/products/platform Maemo a l'air officiellement supporté ou j'ai mal compris?

    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Maemo

      Posté par . Évalué à  2 .

      C'est un petit cafouillage de la part de Nokia/Qt, actuellement, tu ne disposes que d'une technologie preview de Qt 4.6 pour Maemo 5 qui en gros reprend Qt/X11 + quelques extensions propres à Maemo (enfin, ça marche plutôt bien).
      http://qt.nokia.com/developer/qt-for-maemo-developers
      Mais le support de Maemo 5 dans Qt ne sera finalisé que courant 2010, Maemo 6 (prévu en 2011) lui sera basé sur Qt.

Suivre le flux des commentaires

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