Quelle bibliothèque pour du GUI ?

Citation:

---

Envoyé par loufoque

L'interface de Qt c'est plein de pointeurs et autres horreurs, hein. C'est pas vraiment du RAII.

---

C'est pas faux, mais tu peut faire les deux.
Tous les pointeurs que tu doit créer (principalement pour la partie IHM) seront géré par Qt (si tu gère bien les parent/enfant).

Un message fort intéressant vient d'être posté sur la mailing list de GTK+ en réaction à cette annonce :

Citation:

---

Envoyé par [url=http://mail.gnome.org/archives/gtk-app-devel-list/2009-January/msg00067.html]qt vs gtk[/url]

With the recent news that Nokia will be releasing QT under LGPL, I'm seeing allot of knee-jerk anti-GTK comments out there. I know I'm preaching to the choir on this list, but for the sake of moral I thought I would post my 2 cents on the matter.

-I can't think of single QT application I even use. (although I admit I don't look for them)

-Without getting into a C vs C++ debate, being able to use GTK straight from C really is the whole universe right there. Try returning GUI objects from dynamically loadable modules without C. In general, C libraries mix together far better than C++ ones. I use GTK together with all kinds of stuff. I'm younger and learned C++ in school. I had to unlearn the damage. The guys I know that still believe C++ always have this mental model that every library needs to be wrapped in some sort of all-encompassing toolkit, or you can't use it.

-QT (last time I checked) is not even C++. It's C++ and a custom macro language. building ouch. debugging ouch. C++ paradigm ouch.

-HUGE: glib and gtk are separate. glib can be used on it's own. so one mental model to work with for gui and non-gui events.

-When you start getting into it, there is just no contest. I love GTK. I have no doubt that if I started to read about qt, that I would constantly be saying, "oh you can't do that", and "you mean you have to that". Long live GTK!

---

Pour résumer (sans trop d'approximations j'espère) :

• GTK+ étant écrit en C, il se mélange mieux au code C++
• Qt utilise un système de macro qui fait que ce n'est plus du C++ (problème de débugage, entre autre)
• La GLib et GTK+ sont séparés, on retrouve le même modèle pour les applications consoles et graphiques

Je rajouterai pour le dernier point, qu'en utilisant GTK+ (qui dépend de la glib), on regroupe (à la louche) Boost et Qt.

Si vous avez un avis sur la question, n'hésitez pas à poster sur la mailing list (en anglais) et ici pour les anglophobes ;)

Déjà, son commentaire -> poubelle. Au moins, on sait écrire GTK, apparemment lui ne sait pas la différence entre Qt et QT.

Et Qt se place comme concurrent de GTK+, pas GTK. Et s'il a eu du mal à apprendre le C++ en cours, je le comprends, les profs ne sont pas terribles en général.

Le premier point évoqué fait référence aux problèmes d'ABI qui sont le gros point noir du C++ quand on le compare au C.

Et la partie de Qt sans GUI se retrouve effectivement ailleurs (SL, boost, ACE, ...)

Citation:

---

Envoyé par Matthieu Brucher

Déjà, son commentaire -> poubelle. Au moins, on sait écrire GTK, apparemment lui ne sait pas la différence entre Qt et QT.

Et Qt se place comme concurrent de GTK+, pas GTK. Et s'il a eu du mal à apprendre le C++ en cours, je le comprends, les profs ne sont pas terribles en général.

---

Quel argumentaire :aie: Bien évidement qu'il oriente le débat puisque ça vient de la ML GTK+ ! Mais les arguments que j'en ai tiré, t'en pense quoi (c'est aussi l'impression que j'ai eu en testant Qt) ?

Citation:

---

Envoyé par Luc Hermitte

Le premier point évoqué fait référence aux problèmes d'ABI qui sont le gros point noir du C++ quand on le compare au C.

---

Je ne pensais pas à l'ABI mais simplement à la syntaxe. Par exemple pour les signaux :

Code:

---

1 2	QObject::connect(&a, SIGNAL(valueChanged(int)), &b, SLOT(setValue(int)));

---

Code:

---

button.signal_clicked().connect(sigc::ptr_fun(&on_button_clicked));

---

Je trouve la syntaxe de GTK+, plus lisse, idem pour la déclaration des classes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Counter { public: Counter() { m_value = 0; }   int value() const { return m_value; } void setValue(int value);   private: int m_value; };

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <QObject>   class Counter : public QObject { Q_OBJECT   public: Counter() { m_value = 0; }   int value() const { return m_value; }   public slots: void setValue(int value);   signals: void valueChanged(int newValue);   private: int m_value; };

---

On s'éloigne quand même de la syntaxe du C++, non ?

Citation:

---

• Qt utilise un système de macro qui fait que ce n'est plus du C++ (problème de débugage, entre autre)

---

:mouarf: il s'est planté avec wxwidgets :mouarf:
a ma connaissance côté macro en Qt à part Q_OBJECT (et tu n'as pas envie de savoir ce qu'il y as dedans, d'où qmake) c'est un peu le néant

Citation:

---

• La GLib et GTK+ sont séparés, on retrouve le même modèle pour les applications consoles et graphiques

---

Qt est découpé :
QtCOre
QtGui
QtWebKit
...
et Qt peut utiliser glib sous linux. Je ne comprend pas ce qu'il veut dire

donc je suis d'accord : poubelle cette son commentaire
[edit]
ah oui y as aussi signal et slot en macro

Citation:

---

Envoyé par Mongaulois

a ma connaissance côté macro en Qt à part Q_OBJECT (et tu n'as pas envie de savoir ce qu'il y as dedans, d'où qmake) c'est un peu le néant

---

Et le public slot 8O Et les signaux 8O C'est plutôt facile de prendre le moins significatif et de tout balancer sur cette base !

Et même dans ce cas, tout ce qui est ajouter par cette macro devrait être se faire par héritage (surtout que l'on hérite de QObject) :koi:

Citation:

---

Envoyé par Mongaulois

Qt est découpé :
QtCOre
QtGui
QtWebKit

---

Effectivement, je pensais trouver des fonctionnalités qui nécessités boost et Qt mais Qt semble tout réimplémenter. Mais ça fait quand même deux bibliothèques à maitriser selon que l'on ai en mode console ou graphique (à moins de se trimballer Qt dans tous les cas :aie:).

Citation:

---

Envoyé par Mongaulois

donc je suis d'accord : poubelle cette son commentaire

---

Le but n'est pas de troller mais de discuter, vous avez le droits d'avouer que Qt n'est pas parfaite. Avant se message je pensais que Qt était la meilleure solution pour coder des GUI en C++ et gtkmm un gadget mais cette dernière semble avoir des atout pour elle !

Ça ne me dérange pas d'énoncer les inconvénients de gtkmm :

• Il faut installer énormément de bibliothèques (glib, GTK, glibmm, gtkmm, ...),
• Les fonctions C++ appellent les fonctions C ce qui multiplie par 2 les appels de fonctions (problème de performances ?).

Citation:

---

Envoyé par gege2061

Quel argumentaire :aie: Bien évidement qu'il oriente le débat puisque ça vient de la ML GTK+ ! Mais les arguments que j'en ai tiré, t'en pense quoi (c'est aussi l'impression que j'ai eu en testant Qt) ?

---

Pas grand chose... Les problèmes d'ABI, on les a aussi avec GTK+

Citation:

---

Envoyé par gege2061

Je ne pensais pas à l'ABI mais simplement à la syntaxe. Par exemple pour les signaux :

Code:

---

1 2	QObject::connect(&a, SIGNAL(valueChanged(int)), &b, SLOT(setValue(int)));

---

Code:

---

button.signal_clicked().connect(sigc::ptr_fun(&on_button_clicked));

---

---

Faut vraiment que je réponde :D ?
Person, je préfère la première. La seconde est bien plus complexe : on récupère un objet temporaire à partir d'un bouton et on y connecte un pointeur vers une fonction englobée avec je ne sais quoi.
La syntaxe de Qt, c'est on connecte un signal de a sur un slot de b.

Citation:

---

Envoyé par gege2061

Je trouve la syntaxe de GTK+, plus lisse, idem pour la déclaration des classes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Counter { public: Counter() { m_value = 0; }   int value() const { return m_value; } void setValue(int value);   private: int m_value; };

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <QObject>   class Counter : public QObject { Q_OBJECT   public: Counter() { m_value = 0; }   int value() const { return m_value; }   public slots: void setValue(int value);   signals: void valueChanged(int newValue);   private: int m_value; };

---

On s'éloigne quand même de la syntaxe du C++, non ?

---

On va surtout dire que GTK+ n'a besoin de rien de plus, contrairement à Qt qui conserve les signaux et slots depuis avant que le C++ n'existe vraiment.
En revanche, un avantage de signal/slot, c'ets qu'on sait à la lecture ce qui est appelé et ce qui est signalé, contrairement à GTK+ où on doit avoir une convention de nommage. Mais c'est un inconvénient. Le coup du moc, je suis désolé, ce n'en est pas un, les constructeurs classiques (cmake, SCons, Visual, ...) le gèrent de manière transparente.

Citation:

---

Envoyé par gege2061

Et le public slot 8O Et les signaux 8O C'est plutôt facile de prendre le moins significatif et de tout balancer sur cette base !

---

On a tout de même l'avantage avec les signaux de créer un peu n'importe quoi comme événements, je ne sais pas comment c'est fait en GTK+ pour en créer.

Citation:

---

Envoyé par gege2061

Et même dans ce cas, tout ce qui est ajouter par cette macro devrait être se faire par héritage (surtout que l'on hérite de QObject) :koi:

---

Non, car le mécanisme est plus complexe que cela. On n'appelle pas la méthode directement, mais la méta méthode générée par moc (et c'est là où la macro est indispensable), ceci afin de pouvoir passer à travers les threads, faire un virtual sans en faire un, ...

Il y a des trucs accessoires qui sont dérivés de l'architecture, mais elle a fait ses preuves, on va dire. On peut faire mieux, mais on a déjà fait pire (signaux et slots non thread-safe par exemple).

Citation:

---

Envoyé par gege2061

Effectivement, je pensais trouver des fonctionnalités qui nécessités boost et Qt mais Qt semble tout réimplémenter. Mais ça fait quand même deux bibliothèques à maitriser selon que l'on ai en mode console ou graphique (à moins de se trimballer Qt dans tous les cas :aie:).

---

Complémentaires, peut-être. Mais Qt ne réimplémente pas tout Boost, et vice versa. Et surtout Qt va taper sur des plateformes que Boost ignore.

Citation:

---

Envoyé par gege2061

Le but n'est pas de troller mais de discuter, vous avez le droits d'avouer que Qt n'est pas parfaite. Avant se message je pensais que Qt était la meilleure solution pour coder des GUI en C++ et gtkmm un gadget mais cette dernière semble avoir des atout pour elle !

---

Qt est la meilleure solution :D

Citation:

---

Envoyé par gege2061

Ça ne me dérange pas d'énoncer les inconvénients de gtkmm :

• Il faut installer énormément de bibliothèques (glib, GTK, glibmm, gtkmm, ...),
• Les fonctions C++ appellent les fonctions C ce qui multiplie par 2 les appels de fonctions (problème de performances ?).

---

Pour le 1, avec un bon gestionnaire de paquet, on s'en fout. Et Qt a besoin aussi de pas mal de paquets.
Et pour le 2, certains mécanismes de Qt sont bien plus consommateurs, ce n'est pas un niveau de plus qui va être gênant.

Ce qui m'embête le plus dans GTK par rapport à Qt, et qui réduit fortement les inconvénients de Qt (autre manière de fonctionner, différente du C++ traditionnel, NIH, ...), c'est que ce n'est pas aussi joli (désolé, mais c'est vrai, ce n'est pas un vrai argument d'informaticien, mais c'est le mien :D), et aussi que le mécanisme de fonctionnement est encore plus difficile à saisir que Qt.

Citation:

---

Envoyé par gege2061

Et le public slot 8O Et les signaux 8O C'est plutôt facile de prendre le moins significatif et de tout balancer sur cette base !

Et même dans ce cas, tout ce qui est ajouter par cette macro devrait être se faire par héritage (surtout que l'on hérite de QObject) :koi:

---

le moins significatif 8O c'est la plus importante de toute les macro. Et c'est aussi la base pour signal et slot.
Et non elle ne peut être hérité. Elle déclare des fonctions static propre à la classes.

Citation:

---

Le but n'est pas de troller mais de discuter,

---

C'est pour ne pas troller le poubelle, c'est un peu du flan ce qui est écrit.. dsl

Citation:

---

vous avez le droits d'avouer que Qt n'est pas parfaite.

---

euh dans ce thread, ça fait un moment que je dit que Qt n'est pas parfais et qu'il y as une liste de reproche. Après c'est au gout de chaqu'un.

Citation:

---

Avant se message je pensais que Qt était la meilleure solution pour coder des GUI en C++ et gtkmm un gadget mais cette dernière semble avoir des atout pour elle !

---

A chaqu'un son style.

Perso, les signal/slot de Qt sont surement les plus aboutie et puissante :

1. thread safe avec copie et passage par event loop
2. signal avec N paramètres peut être connecter à n'importe quels slot contenant 0 à N paramètres
3. possibilité d'auto-connexion
4. connexion par signature et non par pointeur

Qt on aime ou pas, c'est comme gtk, wxwidget,...

Le problème de GTK+ c'est surtout que ça réimplémente la moitié de Common Lisp en C de manière bugguée et inefficace.
Qt a une moins belle interface, mais est techniquement supérieur.

Citation:

---

Envoyé par Matthieu Brucher

Et Qt se place comme concurrent de GTK+, pas GTK.

---

Tiens, tant qu'on est sur ce sujet, quelle est la différence? Je n'ai jamais vraiment compris... :?

Citation:

---

Envoyé par loufoque

Le problème de GTK+ c'est surtout que ça réimplémente la moitié de Common Lisp en C de manière bugguée et inefficace.
Qt a une moins belle interface, mais est techniquement supérieur.

---

Merci pour le lieu commun, mais tout ce qui n'est pas Common Lisp le "réimplémente de manière bugguée et inefficace"... :roll:

De toute façon, je ne connais pas Common Lisp. Mais il y a une chose que je n'ai pas aimé dans GTK(+), ce sont les casts explicites à tour de bras, notamment des casts de pointeurs de fonctions.

Personnellement, tout ce qui me rebute est là, et la LGPL n'y changera rien :

Citation:

---

-QT (last time I checked) is not even C++. It's C++ and a custom macro language. building ouch. debugging ouch. C++ paradigm ouch.

---

Et j'ajouterais : Analyse du code (reverse engineering) ouch.

Mais franchement, avec les dizaines de pages de conversation qu'on a sur le sujet, vous pensez pas que tout a déjà été dit ?

Pour moi, c'est la même chose, mais avec wx et GTK. Aucune bibliothèque de GUI n'est vraiment 100% C++, elles ont toutes hérité énormément de leur philosophie lors des balbutiements du C++, voir pour GTK de la philosophie C.

Cet argument est pour moi non recevable, pour aucune bibliothèque.

Si je ne m'abuse, seul Qt utilise un mécanisme non-standard pour la résolution des « public signal: » évoqués par Gégé.
Si tu veux faire de l'analyse de code, à moins que l'analyseur supporte expressément Qt, ça ne passera jamais…

Citation:

---

Envoyé par Matthieu Brucher

Aucune bibliothèque de GUI n'est vraiment 100% C++, elles ont toutes hérité énormément de leur philosophie lors des balbutiements du C++, voir pour GTK de la philosophie C.

Cet argument est pour moi non recevable, pour aucune bibliothèque.

---

ASL n'a pas hérité grand chose du passé du C++.

Citation:

---

Envoyé par Florian Goo

Citation:

---

-QT (last time I checked) is not even C++. It's C++ and a custom macro language. building ouch. debugging ouch. C++ paradigm ouch.

---

Et j'ajouterais : Analyse du code (reverse engineering) ouch.

---

:koi:
sérieux, vous parlez vraiment de Qt là????
Qt as en gros Q_OBJECT,signal et slot. C'est la seule raison de l'existence de moc. Cela permet de faire énormément de chose très puissante, et certainement encore inégalé.
Moc ne fait que générer du code C++ pour toi. Tu développe en Qt comme tu développe en C++. L'histoire des signal et du slot, c'est pas compliqué.

building ouch : Qt fourni tous ce qu'il faut pour appliquer correctement moc. Après y as rien d'obscure. Comme dit mathieu

Citation:

---

Les constructeurs classiques (cmake, SCons, Visual, ...) le gèrent de manière transparente.

---

debugging ouch : alors là c'est ...n'importe quoi. Le debugage est exactement pareil.

C++ paradigm ouch : tout dépend par ce que tu entend par là... Pourquoi on ne pourrais pas faire du vrai C++ ???? Qt (pour raison historique et homogénéité du framework) as créé une pseudo STL compatible. Il y as le RAII, et les seule moment ou tu doit faire des pointeurs, ils seront gérés par l'association parent/enfant. Et tu peut à tout moment détruire un de ces pointeurs, si vraiment tu en as envie. Tu peut simplement mixer Qt et boost. Tu peut mixer les signal slot Qt et boost :
http://irmatden.developpez.com/tutor...boost-signals/

Analyse du code (reverse engineering) ouch. : je veut bien que tu m'explique en quoi.

Citation:

---

Envoyé par Florian Goo

Mais franchement, avec les dizaines de pages de conversation qu'on a sur le sujet, vous pensez pas que tout a déjà été dit ?

---

certainement oui. Si j'ai reprise ce thread c'est parce que c'est celui qui était le plus objectif. Mais là ça dérive en côté obscure de Qt. Jamais personne n'as dit qu'il est parfais et qu'il plaira à tout le monde. Et j'ai pas envie de défendre indéfiniment Qt à des personnes (je parle en générale ne le prend pas pour toi) qui n'ont jamais essayés ou essayés de comprendre pourquoi Qt as fait ceci ou cela.

Si tu veut un peu de doc regarde juste ceci :
http://qt.developpez.com/doc/4.4/object/

Si tu as une solution pour palier au moc, tout en gardant la puissant des signal/slot et meta donné, je suis intéressé. Peut être qu'il y as des choses utilisable dans C++0x.

Bien sure, Qt peut être reprochable sur plusieurs point. Mais c'est pareil pour toutes bibliothèques.

Citation:

---

Envoyé par Florian Goo

Si je ne m'abuse, seul Qt utilise un mécanisme non-standard pour la résolution des « public signal: » évoqués par Gégé.
Si tu veux faire de l'analyse de code, à moins que l'analyseur supporte expressément Qt, ça ne passera jamais…

---

Tu as surement raison. Mais je me pose une question (je ne connait pas beaucoup les analyseur de code)

Signal et slots sont de simple macro qui ne font pas grand chose

Citation:

---

# define slots
# define signals protected

---

Si pour un compilateur ça ne lui pose pas de problème, es ce que cela devrais pour un analyseur de code?

Sinon, le seule truc que j'espère c'est que Qt ne va pas être idéalisé comme sur un autre forum...

Au temps pour moi, je pensais que ces macros (signals et slots) étaient beaucoup plus obscures que ça (au point de ne pas être vraiment des macros au sens préprocesseur C standard) :oops:.
Un analyseur de code se comporte comme un compilateur (du moins c'est comme ça que je m'y prends pour mon projet) : preprocessing, puis analyse syntaxique/sémantique, etc., sauf qu'au lieu de sortir un binaire, ça sort des structures de données plus intelligibles pour une génération de diagramme UML de classes, par exemples.
Donc oui, si un compilateur s'en sort nativement, un analyseur en fera autant.

Quel est l'intérêt de ces macros, dans ce cas ? Elles rebutent les puristes plus qu'autre chose…

Citation:

---

Envoyé par Florian Goo

Quel est l'intérêt de ces macros, dans ce cas ?

---

C'est surement là où il peut y avoir un problème avec un analyseur.

Quand la macro Q_OBJECT est présente, moc va générer du code C++:
1- pour les méthode contenue dans signal
2- pour les fonction static déclaré par la macro Q_OBJECT et la gestion des meta pour les signal et les slot.

Qt créé des meta donné qui lui sert à énormément de chose par la suite.

Ce code C++ peut soit :
1- être compilé est linké
2- soit inclus.

Citation:

---

Envoyé par Florian Goo

Elles rebutent les puristes plus qu'autre chose…

---

surement car en soit même elle ne semble servir à rien mais qu'elles servent à de la génération de code.

Citation:

---

Envoyé par Florian Goo

Quel est l'intérêt de ces macros, dans ce cas ? Elles rebutent les puristes plus qu'autre chose…

---

moc en a besoin pour créer son code.