(En ce qui me concerne c'est du Ruby mais la question Gtk/Qt est la même. ;o)
Je viens de réaliser un petit programme à la fois en Gtk, avec libglade, et en Qt, avec QWidgetFactory. Le principe étant, dans les deux cas, de ne pas générer de code mais de charger le fichier .glade/.ui réalisé sous Glade/Kdevdesigner (les deux sont du XML, dont aussi modifiables « à la main »). Ce fichier est modifiable indépendamment du code.
Je peux te donner quelques points positifs (+) et négatifs (-) des deux approches :
Gtk :
+ la libglade est très bien faite ;
+ Glade est assez sympa, il permet de manipuler toutes les propriétés des widgets ;
- la gestion de la mise en place (layouts) est assez casse-bonbon si on a pas décidé à priori (p.ex., si on oublie une colonne au milieu, il faut faire des couper-coller pour déplacer le contenu des colonnes à droite, quand ça fait pas planter le bouzin) ;
- Glade est multi-fenêtre à la Gimp (normal) ;
+ le MVC des GtkTreeView (et autres) : j'aime bien le MVC ;
- le MVC des GtkTreeView : ce n'est pas super pratique de jongler avec le modèle du TreeView et notre propre modèle ;
+ les icônes et les boutons prédéfinis dans Glade.
Glade s'oriente de plus en plus vers l'utilisation de la libglade (Glade-3 n'aura plus de générateurs de code intégré (mais on pourra toujours le faire)).
Qt :
+ la gestion des positions est plus pratique : on place les objets et on les groupe ensuite, on peut changer d'avis à tout moment ;
- pas de vrai MVC pour les QListView ;
+ mais il suffit d'hériter de QListViewItem pour coupler son modèle avec le QListView, donc MVC facile ;
- on ne peut pas faire du KDE avec QWidgetFactory (la classe qui construit les objets à partir du .ui) : dommage, il y a des fonctionnalités sympas dans les classes K ;
+ les connexions entre signaux (événements) et slots (callbacks) se fait graphiquement : on trace une flêche entre deux widgets ;
- une seule fenêtre/dialogue par .ui (ça limite l'utilité du point précédent).
Qt est plus orienté vers la génération de code. L'héritage y est préféré à l'utilisation.
Qt4 utilise(ra) le xml pour définir les menus et les barres à outils mais la création dynamique à partir du .ui est laissée de côté.
En fait, je n'ai pas vraiment de préférence pour l'un ou pour l'autre : libglade est super mais j'ai tendance à préférer la philosophie objet de Qt.
J'aurais peut-être un peu plus d'arguments quand je me serai vraiment attaqué à l'internationalisation de l'application.
# Retour d'expérience fraîche
Posté par Sylvain Sauvage . En réponse au message PyGTK OU PyQT. Évalué à 3.
Je viens de réaliser un petit programme à la fois en Gtk, avec libglade, et en Qt, avec QWidgetFactory. Le principe étant, dans les deux cas, de ne pas générer de code mais de charger le fichier .glade/.ui réalisé sous Glade/Kdevdesigner (les deux sont du XML, dont aussi modifiables « à la main »). Ce fichier est modifiable indépendamment du code.
Je peux te donner quelques points positifs (+) et négatifs (-) des deux approches :
Gtk :
+ la libglade est très bien faite ;
+ Glade est assez sympa, il permet de manipuler toutes les propriétés des widgets ;
- la gestion de la mise en place (layouts) est assez casse-bonbon si on a pas décidé à priori (p.ex., si on oublie une colonne au milieu, il faut faire des couper-coller pour déplacer le contenu des colonnes à droite, quand ça fait pas planter le bouzin) ;
- Glade est multi-fenêtre à la Gimp (normal) ;
+ le MVC des GtkTreeView (et autres) : j'aime bien le MVC ;
- le MVC des GtkTreeView : ce n'est pas super pratique de jongler avec le modèle du TreeView et notre propre modèle ;
+ les icônes et les boutons prédéfinis dans Glade.
Glade s'oriente de plus en plus vers l'utilisation de la libglade (Glade-3 n'aura plus de générateurs de code intégré (mais on pourra toujours le faire)).
Qt :
+ la gestion des positions est plus pratique : on place les objets et on les groupe ensuite, on peut changer d'avis à tout moment ;
- pas de vrai MVC pour les QListView ;
+ mais il suffit d'hériter de QListViewItem pour coupler son modèle avec le QListView, donc MVC facile ;
- on ne peut pas faire du KDE avec QWidgetFactory (la classe qui construit les objets à partir du .ui) : dommage, il y a des fonctionnalités sympas dans les classes K ;
+ les connexions entre signaux (événements) et slots (callbacks) se fait graphiquement : on trace une flêche entre deux widgets ;
- une seule fenêtre/dialogue par .ui (ça limite l'utilité du point précédent).
Qt est plus orienté vers la génération de code. L'héritage y est préféré à l'utilisation.
Qt4 utilise(ra) le xml pour définir les menus et les barres à outils mais la création dynamique à partir du .ui est laissée de côté.
En fait, je n'ai pas vraiment de préférence pour l'un ou pour l'autre : libglade est super mais j'ai tendance à préférer la philosophie objet de Qt.
J'aurais peut-être un peu plus d'arguments quand je me serai vraiment attaqué à l'internationalisation de l'application.