Quelle bibliothèque pour du GUI ?

Citation:

---

Envoyé par epsilon68

MAT007 tu pourrais nous dire les problemes que tu rencontres au jour le jour dans l'utilisation de Qt?

---

C'est pas vraiment des problèmes, en tous cas rien d'insurmontable, c'est surtout un fort sentiment de lutter constamment contre Qt.
Par exemple ce que dit MonGaulois sur qmake me fait bien halluciner, moi il est hors de question d'avoir un système de build imposé par une bibliothèque...

Je trouve que c'est comme ça pour un peu tout, Qt impose tout le temps plein de trucs, en général à l'encontre de la philosophie de la communauté C++ type boost.
Et des fois ça coince et je passe 1/2 journée à essayer de remanier les créations/destructions et à forcer plein de delete manuels des composants dans les destructeurs de leurs parents parce que le modèle de gestion n'est pas vraiment compatible avec la manière dont on fait le reste (bon c'est aussi que les applications graphiques sont considérées comme pas importantes là où je travaille et que tout le monde fait ça à l'arrache, ça n'aide pas).

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

MAT.

Citation:

---

Envoyé par Mat007

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

---

+1

Citation:

---

Envoyé par Mat007

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

---

Justement je trouve que c'est plutot un avantage certain.
par example le module SQL est tres pratique et s'integre parfaitement avec le reste du code, pareil pour le XML, pareil pour le Concurrent etc...

moi je n'utilise que qmake, j'aime vraiment bien cet outil, simple et puissant.

et la doc de Qt est un vrai plaisir :-)

Citation:

---

Envoyé par Mat007

Par exemple ce que dit MonGaulois sur qmake me fait bien halluciner, moi il est hors de question d'avoir un système de build imposé par une bibliothèque...

---

Tu n'as aucune obligation, c'est juste un outils qu'il t'offre pour te simplifier la vie. Tu peut très bien utiliser d'autre générateur de makefile ou faire "à la main". SCONS, CMAKE et autre gère Qt. moc et uic ne sont que des générateurs de code. Rien de plus.

Code:

---

Je trouve que c'est comme ça pour un peu tout, Qt impose tout le temps plein de trucs, en général à l'encontre de la philosophie de la communauté C++ type boost.

---

:koi:
comme????

Citation:

---

Et des fois ça coince et je passe 1/2 journée à essayer de remanier les créations/destructions et à forcer plein de delete manuels des composants dans les destructeurs de leurs parents parce que le modèle de gestion n'est pas vraiment compatible avec la manière dont on fait le reste

---

Ben si tu peut sans problème utiliser des delete. Tu peut aussi spécifier la destruction lorsqu'une widget est fermé avec l'attribut :
Qt::WA_DeleteOnClose
J'ai plus l'impression que ton problème est que tes traitements sont mélangés avec ton ihm

Je ne cherche pas à défendre Qt. Mais à être objectif.

Citation:

---

Envoyé par dtrosset

Citation:

---

En bref ce que je reproche à Qt c'est d'être un framework alors que j'ai juste besoin d'une bibliothèque.

---

+1

---

:koi:
GTK et WxWidget sont aussi gros!!! quasiment les même fonctionnalités!!! avec de ce que j'ai vue beaucoup plus de dépendance que Qt!!!
Boost est bien plus gros!

Je ne voie pas ce que vous voulez dire.

Personnellement j'ai utilisé wxWidgets par le passé (quand je dis par le passé, c'est que ça fait longtemps que je n'ai pas eu à faire d'ihm).
Sur le papier ça me semble excellent, c'est juste une surcouche de la lib graphique native du système (MSW, Mac, GTK, …) avec une API commune. D'ailleurs le poids des DLL et la facilité de déploiement s'en ressentent.
Par contre, en pratique je dois dire que je n'aime pas trop l'API :

• Système de gestion d'évènements particulièrement cradingue à base d'enums et de macro
• Ils n'ont pas l'air de savoir ce qu'est un namespace
• Utilisation obligatoire de l'allocation dynamique pour les objets graphiques
• le main() n'est pas accessible (utilisation forcée d'une macro qui l'implémente)

Mais bon, ça fait très bien ce qu'on lui demande et on est pas trop « envahi » par cette lib (si ce n'est la class wxString et les _T"" qui vont avec). Comme il a été dit, ce n'est pas un framework mais une bibliothèque seulement. Même si ils fournissent une lib de gestion des threads (merdique, de mémoire) et d'autres trucs du même acabit, tout cela n'est pas lié aux composants graphiques.


Qt, je ne connais pas trop. Je me suis renseigné rapidement dessus, et j'ai fait demi-tour aussi vite que je suis arrivé. Deux gros points noirs rédhibitoires :

• redondances omniprésentes de la STL (qlist et consort)
• et surtout, son utilisation peut mener à du C++ non-standard (d'où le préprocesseur made-in Qt)

Un exemple pour illustrer ce dernier point :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class Counter : public QObject { Q_OBJECT   public slots: void setValue(int value);   signals: void valueChanged(int newValue); };

---

Les adorateurs de Qt trouvent ça pratique (et ils doivent avoir raison), mais personnellement, ça me pique les yeux.
L'utilisation forcée de leur préprocesseur n'est pas le seul inconvénient lié au fait que le code ne soit pas standard. Par exemple, allez faire du reverse-engineering là dessus…


Enfin, plus récemment, je me suis attelé à l'utilisation de gtkmm. Je ne l'ai utilisé que sous Linux pour un projet perso pas encore déployé, donc je ne peux pas appuyer ses propos concernant la facilité de déploiement, mais je peux dores et déjà dire que j'ai vraiment l'impression de faire du C++ quand je code avec (ce qui est plutôt drôle étant donné que c'est la seul lib des trois que ne soit qu'un binding du C).
C'est d'ailleurs un des arguments avancés par les dévs de gtkmm eux-mêmes (eux-mêmêmes :D) :

Citation:

---

Envoyé par http://www.gtkmm.org/

(…)
# Type-safe signal handlers, in standard C++.
(…)
# Use of Standard C++ Library, including strings, containers, and iterators.
(…)
# Full use of C++ namespaces.
# No macros.

---

Malheureusement, GTK ne s'intègre pas excellemment bien sous Windows (même si c'est pas tellement hideux). Pour un exemple, installez Wireshark (ex-Ethereal) ou Gimp.


Bref, le graal reste encore à être fait, selon moi.
Un truc avec les mêmes spec que wxWidgets (surcouche portable) avec une qualité de réalisation équivalente à celle de gtkmm, une bonne cohérence avec la STL et qui laisse gérer les trucs style threads, sockets et consort à ceux qui savent faire.

Citation:

---

Envoyé par three minute hero

Qt, je ne connais pas trop. Je me suis renseigné rapidement dessus, et j'ai fait demi-tour aussi vite que je suis arrivé. Deux gros points noirs rédhibitoires :

• redondances omniprésentes de la STL (qlist et consort)

---

C'est surtout qu'il utilise énormément le COW. Ils ont donc recréé leurs conteneur. Et historiquement il me semble que certain compilo avais une mauvaise implémentation de la STL

Citation:

---

Envoyé par three minute hero

• et surtout, son utilisation peut mener à du C++ non-standard (d'où le préprocesseur made-in Qt)

---

Le non-standard s'arrête là. Qt utilise énormément de meta-donné sur les class, en autre pour le les signal/slot.
Le moc est juste là pour simplifier la vie de développeur et surtout pour éviter des macro immonde.
J'avais lue que le moc est aussi une raison historique où il palliais à des manque du C++ de l'époque.

Aprés Qt est vieux, as un historique et une quantité de compilateur à supporter. Ce qui forme un sous-ensemble plutôt critiqué.

Gtkmm est beaucoup plus jeune et semble plus proche du C++ et surtout des compilo récent.

Toute façon toute ces api sont très proches. Au final c'est juste un choix de style de programmation.

humm je pense que le MOC a tout son intérêt quand ils ont besoin de rajouter des choses sans faire appel au programmeur. il permet de retirer l'observation au delete de l'objet par exemple, mais aussi de stoker les informations de l'objet. Avec Qt/Javascript, on voit qu'il faut ce genre d'information sans que ce soit une douleur pour le programmeur.

bref quand tu ne veux pas etre dependant de Qt (je suis aussi d'accord), on se rend malgré tout dependant d'une autre lib

on se dit qu'il ne vaut mieux pas devenir 100% dependant de Qt donc on se rajoute la maintenance de plusieurs libs (par ex. libxml2, soci++,etc)

par contre bienvenu dans le cauchemard de la maintenance des multiples libraries et de l'interface entre librairies. Maintenant je ne peux honnetement pas assumer tout seul la maintenance de toutes ces couches... avec Qt je peux au moins avancer dans mon produit, et me concentrer sur les fonctionnalités plutot que dans les couches d'abstractions de plusieurs lib et dependances.

au final de toute facon, si Qt est abandonné, bein ca reviendrait dans 90% des cas a refaire l'appli en la reconstruisant avec les bout de codes, composants qu'on pourrait reutiliser... On serait de toute facon dans le meme ordre de grandeur de difficulté.

Ce ne sont que des compromis, ou le temps de developpement joue un role essentiel.

ok petite question sur gtkmm
me basent sur ce que je fait avec mes librairies. a savoir faire des librairie statique ou dynamique.
et t il possible sans m arracher le peu de cheveux qui me reste :lol: de faire un executable qui contiendrai tout les librairie (de gtkmm et autre gui )dont j aurai besoin pour mon application pour ne pas avoir a installer gtk a chaque fois que je le fait tourner sur une autre machine ??

Citation:

---

Envoyé par epsilon68

h
au final de toute facon, si Qt est abandonné, bein ca reviendrait dans 90% des cas a refaire l'appli en la reconstruisant avec les bout de codes, composants qu'on pourrait reutiliser...

---

Pas la peine, le deale fait avec KDE est qu'il récupèrerons tout les droit si quelque chose comme cela arrivais ;)
Donc Qt ne risque pas de disparaitre :P

Citation:

---

Envoyé par Mongaulois

Pas la peine, le deale fait avec KDE est qu'il récupèrerons tout les droit si quelque chose comme cela arrivais ;)
Donc Qt ne risque pas de disparaitre :P

---

cela ne concerne que Qt/X11 si je me rappelle bien :-)

Citation:

---

Envoyé par epsilon68

cela ne concerne que Qt/X11 si je me rappelle bien :-)

---

Ben ils parlent des dernière sources donc les autres OS sont inclus dedans, non?
Puis Maintenant Que Qt est en GPL, n'importe qui peut reprendre en continuer

Citation:

---

Envoyé par Mongaulois

GTK et WxWidget sont aussi gros!!! quasiment les même fonctionnalités!!! avec de ce que j'ai vue beaucoup plus de dépendance que Qt!!!
Boost est bien plus gros!

Je ne voie pas ce que vous voulez dire.

---

C'est pas vraiment une question de volume ou de dépendances mais de philosophie d'utilisation : Qt est plus dans le style à fournir un cadre pour réaliser une application en t'indiquant où et comment personnaliser certaines parties.

Citation:

---

Envoyé par Mongaulois

Tu n'as aucune obligation, c'est juste un outils qu'il t'offre pour te simplifier la vie. Tu peut très bien utiliser d'autre générateur de makefile ou faire "à la main". SCONS, CMAKE et autre gère Qt. moc et uic ne sont que des générateurs de code. Rien de plus.

---

Y'a rien d'obligatoire dans Qt, c'est juste systématiquement la méthode qu'ils conseillent d'utiliser et on a l'impression qu'ils ont un malin plaisir à réinventer la roue à l'opposé de ce qui existe déjà.

Citation:

---

Envoyé par Mongaulois

Citation:

---

Envoyé par Moi

Je trouve que c'est comme ça pour un peu tout, Qt impose tout le temps plein de trucs, en général à l'encontre de la philosophie de la communauté C++ type boost.

---

:koi:
comme????

---

Comme toutes ces choses dans la philosophie Qt qui sont un peu particulières (gestion de la mémoire, signaux, avoir recours à des exécutables pour générer des trucs pour un oui ou un non, etc...) et qui influent sur la manière de l'utiliser (des new partout, une hiérarchie des composants père-fils, etc..).

Je conçois tout à fait que Qt puisse répondre aux besoins de plein de monde, c'est juste que je n'adhère pas à la philosophie...

MAT.

J'aime Qt pour la cohérence de l'ensemble.
J'apprecie qu'ils aient une philosophie et qu'ils s'y tiennent.

Citation:

---

Comme toutes ces choses dans la philosophie Qt qui sont un peu particulières (gestion de la mémoire, signaux,

---

C'est si particulier que cela? je ne pense pas.

Code:

---

avoir recours à des exécutables pour générer des trucs pour un oui ou un non, etc...)

---

Enfin ça s'arrête à l'utilisation pour les connect/source.

Tu peut même te passer du uic en chargeant le .ui dynamiquement (comme glade si je me trompe pas)
Puis c'est pas nouveau des lib qui te fournisse des outils pour générer des bout code :
Bison, adobe.ASL, ...
Je trouve cela propre. Il te permette d'éviter :arf: à cause de subtiliser qui ne nous sert à rien de connaitre

Après, je comprend très bien que cela ne plaise pas à tout le monde. Gtkmm semble plus être dans ta philosophie.

Citation:

---

Envoyé par dtrosset

Et j'ai le même problème avec Python : tkInter, PyQt ou PyWidgets ?

---

Autant j'aime Qt pour son côté C++, et pas wxWidgets, autant sous Python, je préfère wxPython qui a une interface très bien faite à la Python, contrairement à PyQt qui ne ressemble pas à du Python.

En fait ce qu'il manque à wxWidgets c'est... un wrapper C++ :)
Non, sans rire. On peut déjà lancer que wxWidgets n'est pas du C++, mais du C with classes. L'intérêt n'est pas seulement historique vis-à-vis de la compatibilité des compilateurs, il y a aussi le fait que c'est tout aussi facile de créer un wrapper pour cette biblio que pour une biblio C (on ne pourrait pas en dire autant de boost par exemple, swig aime moyennement les templates), c'est ce qui explique qu'on en trouve autant. A partir de la, une surcouche en "vrai" C++ semble être dans la logique des choses.

Perso j'ai essayé d'utiliser une seule fois et ça m'a paru "moins pire" que les anciennes MFC, d'où mon interet.


Par contre le truc d'Adobe a l'air sympas...

Bonjour à tous,
J'ai eu récemment à faire un choix entre QT wxwidget venant du monde majique de Builder C++ et j'ai finit par opter pour QT pour les raisons suivantes:

- C'est super professionnel comparé à wxwidget qui fait bricolage et le C...
- Une enorme communauté sur QT, au moindre probléme j'ai la solution dans l'heure qui suit. Et ca c'est super important.
- Pour les détracteur de qmake, je n'ai jamais eu besoin d'en ecrire un encore moins d'un utiliser un.
- Les moc et Uic, c'est contraigant mais vraiment simple
- Une fois compilé en static QT permet de ne fournir qu'un exe unique.
- par contre effectivement c'est pas donné, compter 5000€

Avec QT ce qui est à mon sens super important et de bien choisir son IDE, c'est ce qui va faire que QT devient super simple ou super compliqué. Et pour ma part au contraire de beaucoup de spécialistes de QT je conseille d'utiliser Qdesigner qui fournit une interface vraiment commode au developement de GUI

Qt et pas QT
:evilred::evilred::evilred::evilred::evilred::evilred: