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.
Aller plus loin
- QT Gitorious (8 clics)
- Gitorious (3 clics)
- Qt Software (12 clics)
- Téléchargements (9 clics)
# Le premier test
Posté par soulflyb (Mastodon) . Évalué à 3.
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 redkite . Évalué à 5.
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 alice . Évalué à 1.
[^] # Re: signals/slots?
Posté par meuh31 . Évalué à 4.
Pour plus d'infos, profite de la superbe doc QT : http://doc.qtsoftware.com/4.5/signalsandslots.html
[^] # Re: signals/slots?
Posté par alberthier (site web personnel) . Évalué à 7.
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 Dring . Évalué à 4.
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 alberthier (site web personnel) . Évalué à 5.
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 Philippe F (site web personnel) . Évalué à 1.
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 alice . Évalué à 1.
- 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 jMax . Évalué à 2.
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 Octabrain . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.