Qt Software ouvre Qt à la communauté et publie Qt Jambi 4.5

Posté par . Modéré par Mouns.
Tags : aucun
13
12
mai
2009
Communauté
Qt Software vient d'ouvrir une plate-forme de développement destinée à accueillir les contributions de la communauté. Les projets accessibles dans ce contexte sont Qt bien sûr, mais aussi Qt Jambi et Qt Creator (un IDE pour Qt). L'environnement choisi pour cette plate-forme est Gitorious.

Dans un même temps Qt Software sort la version 4.5 de l'API Java pour Qt : Qt Jambi. Comme annoncé précédemment suite au rachat de Qt Software par Nokia, c'est la dernière version de Qt Jambi officiellement prise en charge par Qt Software.

Espérons que la communauté trouvera les ressources et les compétences pour faire vivre et évoluer cette API qui présente de nombreux avantages sur ses concurrents SWT ou Swing, notamment grâce au système signal/slot propre à Qt et à l'existence d'outils de création d'interfaces graphiques libres et gratuits tel que le greffon Qt Jambi pour Eclipse.
  • # Le premier test

    Posté par . Évalué à 3.

    Le premier test pour la communauté sera de voir quand la version 64bits du plugin d'intégration de qt-jambi dans eclipse va sortir.
    C'était en effet une demande forte à laquelle Qt Software n'avait jamais donné suite.

    Ceci étant dit, Qt Software a libéré le code source, mais pour les utilisateurs de Qt Jambi, tout reste à faire...
  • # Enfin !

    Posté par . Évalué à 5.

    Génial, on va enfin pouvoir faire parvenir nos patchs facilement. Gitorious a l'air vraiment pas mal !
    Il y a déjà 15 propositions de merges pour le projet Qt en un jour ^^ du boulot en perspective pour les 13 validateurs :-D
  • # signals/slots?

    Posté par . Évalué à 1.

    Quel est la différence avec le modèle notifier/listener de Swing?
    • [^] # Re: signals/slots?

      Posté par . Évalué à 4.

      Le concept ressemble fortement.

      Pour plus d'infos, profite de la superbe doc QT : http://doc.qtsoftware.com/4.5/signalsandslots.html
    • [^] # Re: signals/slots?

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

      Le système de signaux/slots de Qt est similaire à un modèle de notifier/listener mais est plus pratique à utiliser:
      Pas besoin d'hériter d'une interface de base, la vérification de la compatibilité des signatures du signal et du slot se fait au runtime:

      connect(myQPushButton, SIGNAL(clicked()), this, SLOT(theButtonHasBeenClicked());

      Ca évite de devoir hériter de tout un tas d'interfaces de base (le C++ ne dispose pas de classes anonymes)

      Ca permet aussi un peu plus de souplesse: on peut connecter un signal à un slot qui a moins de paramètres:

      connect(myObject, SIGNAL(eventHappened(int, QString, float)), this, SLOT(handleEvent(int));
      • [^] # Re: signals/slots?

        Posté par . Évalué à 4.

        Une vérification qui est faite à l'exécution plutôt qu'à la compilation, je trouve pas ça "plus pratique", bien au contraire.

        Et je vois pas d'avantage face à Swing, qui bien que complexe à la première approche, est d'une souplesse redoutable. Du moins du point de vue programmeur.

        Parce que d'un point de vue utilisateur, j'ai aucun doute : une interface basée sur Qt c'est quand même mieux intégré que du Swing, même avec la dernière skin qui roxorise des ours polaires.
        • [^] # Re: signals/slots?

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

          Le fait que la vérification de signature se fasse au runtime n'est pas un avantage pour moi non plus, c'est plus ou moins un mal nécessaire.

          Comme dit, le C++ n'as pas de classes anonymes, donc si tu veux faire comme en Java, il faudrait que ta classe qui traite les clics et autres évènements hérite de tout un tas d'interfaces: ClickListener, FocusListener, ValueChangedListener, etc... en fonction de ce que tu veux faire. En plus si tu as deux boutons, les deux vont appeler ClickListener::clicked() et c'est à toi de chercher de quel bouton vient le clic. Les classes anonymes de Java résolvent ce problème.

          Là où le système de Qt est super souple c'est que ton slot a juste besoin de correspondre à la signature du signal et paf, ça marche, une ligne de code et la connection est faite. Perso, je trouve ça même plus pratique que le système de Java, mais ça c'est plus une question de goût qu'un véritable argument.

          Qt utilise moc, un préprocesseur pour faire cela. En C++, il est possible d'écrire un système de signaux/slots sans préprocesseur, libsigc++ et boost le font à l'aide de templates. C'est assez similaire à l'utilisation. Ça n'a pas été utilisé par Qt pour des raisons historiques: à l'époque de Qt 1/2 tous les compilateurs C++ supportés par Qt ne géraient pas bien les templates. Du coup quitte à se coltiner un préprocesseur autant lui faire faire un max de chose, genre ajouter des possibilités d'introspection. En Qt 4 il est maintenant possible d'invoquer un méthode par son nom:

          QMetaObject::invokeMethod(this, "myMethod", Q_ARG(int, 1));
        • [^] # Re: signals/slots?

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

          Pour les avantages par rapport à Swing, je pense que tu as cité le principal : c'est beaucoup moins complexe.

          Il y a besoin de beaucoup beaucoup moins de code pour faire la même chose. D'où gain de temps phénoménal en développement. Pas besoin d'une classe anonyme pour mettre en relation deux objets.

          En ce qui me concerne, à chaque fois que je fais du java, c'est là que je souffre : c'est verbeux, verbeux, verbeux. Et que je te crée 10 classes pour faire un truc super simple.

          Il me semble aussi que les interfaces Swing sont poussives (pour rester poli) alors que Qt est en général plutôt très réactif.

          Après, si tu es super à l'aise dans Swing et que tu trouves que c'est extraordinaire, Qt ne te fera surement pas changer d'avis car c'est différent.

          Pour les signature signal/slot vérifiés au runtime, c'est un compromis qui permet de garder pas mal de souplesse dans Qt. D'autres lib comme boost ont fait un compromis différent et connectent des signaux et des slots avec verif à la compilation, au prix de moins de flexbilité au runtime.
          • [^] # Re: signals/slots?

            Posté par . Évalué à 1.

            D'accord Qt c'est bien en C++, mais les 'avantages sur ses concurrents' donnés dans le journal ne sont pas valables en Java:

            - les signals/slots sont inférieurs aux notifiers/listeners : vérifiés seulement à la compilation, difficile de transformer les arguments...
            - QtDesigner semble assez primitif par rapport aux outils équivalents de Swing et SWT.
            • [^] # Re: signals/slots?

              Posté par . Évalué à 2.

              Je ne connais pas vraiment Swing, mais pour avoir bricolé un peu en SWT, je peux t'assurer que pour ma part je vois effectivement beaucoup d'avantages pour Qt Jambi sur ses concurrents.

              Effectivement, les signals/slots sont vérifiés seulement à la compilation, mais comme il est dit plus haut, avec QtJambi, tu fais en deux lignes ce qui te prends 3 classes et 150 lignes avec les autres.

              À ma connaissance, Qt Designer est le seul outil libre digne de ce nom permettant de définir des interfaces avec Eclipse. C'est peut-être pas un avantage pour toi, mais pour moi si ! Ceci étant, si tu en as à me proposer, je suis toute ouïe.
      • [^] # Re: signals/slots?

        Posté par . Évalué à 2.

        Non le réel intérêt, c'est que les évènements ont bien plus de "sens". On peut par exemple connecter le signal "currentFontChanged" d'un widget de sélection de font à la méthode (qui est aussi un slot) "setFont" d'un widget d'édition de texte.


        De plus, le fait de pouvoir utiliser n'importe quelle méthode et ne pas être forcé par le nom évite de devoir faire comme en Java (de mémoire) au choix :

        public void actionPerformed(Event ev) { // un bouton cliqué
        if (ev.getSource() == monBouton1) {
        // faire un truc
        } else if (ev.getSource() == monBouton2) {
        // etc
        }
        }

        ou

        monBouton1.addActionListener(new ActionListener() {
        public void actionPerformed(Event ev) {
        // faire un truc
        }
        });
        monBouton2.addActionListener(new ActionListener() {
        public void actionPerformed(Event ev) {
        // etc
        }
        });


        Mais faire (de mémoire)

        connect(monBouton1, SIGNAL("clicked()"), monObjet, SLOT("bouton1clique"));
        connect(monBouton2, SIGNAL("clicked()"), monObjet, SLOT("bouton2clique"));

        Et avoir une méthode séparée pour chaque.

Suivre le flux des commentaires

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