Journal Choix toolkit C/C++ : gtk[mm] vs wxWidgets vs Qt

Posté par  .
Étiquettes : aucune
0
25
mai
2004
Dans le cadre de mes études, je vais réaliser un petit projet ( un mois à temps complet ) : pilotage d'un réseau de trains électriques par port série, auquel je souhaite ajouter une (simple dans un premier temps ) interface graphique, comme quelques boutons radio pour des aiguillages, des barres "de mixer audio" pour régler la vitesse des moteurs etc...

Compte tenu du délai d'apprentissage court, que me conseilleriez vous ?

Qt est pour moi le plus "visible" et le plus "rassurant" ( existence de Qt designer, documentation de Trolltech très bien faite, mise en page, etc, intégration à Kdevelop ), mais quels sont vos expériences personnelles et conseils, un toolkit mérite t'il qu'on s'intéresse particulièrement à lui, même si au premier abord il apparaît plus "difficile"?

Je vous demande de ne pas être objectifs : c'est votre expérience qui m'intéresse.

(nb : j'avais trouvé ce journal, mais il y avait à peu près un toolkit différent par réponse...
http://linuxfr.org/~seginus/12086.html(...)
)
  • # Choix toolkit C/C++ : gtk[mm] vs wxWidgets vs Qt

    Posté par  . Évalué à 3.

    Personellement, je n'ai utilisé que Gtk, en C et en C++

    Et la, j'en arrive à un point ou ca commence à me saouler.
    Pour une appli graphique un tant soit peu complexe, faut oublier le C, parce que ca devient trop vite "spaghetti". En c++, je trouve que le binding Gtk (gtkmm) manque de propreté. C'est loin de ce que j'entend dire à propos de QT.

    Mes prochains projets, ce sera en C++ (meme si c'est pas génial comme langage orienté objet), ou ptet en Python, mais avec QT. Je ne peut que te conseiller QT, j'en entend dire que du bien, c'est peut etre un peu plus long à apprendre au début que Gtk, mais à long terme je pense que c'est mieux.
    • [^] # Re: Choix toolkit C/C++ : gtk[mm] vs wxWidgets vs Qt

      Posté par  . Évalué à 2.

      je pense la meme chose,
      néanmois si cest pour un petit projet gtk peut etre plus simple et plus rapide pour a appréhender (par contre je connais pas wx)
      Pour du "long terme" je vote qt sans hésiter, surtout que c est beaucoup plus qu un simple toolkit graphique
  • # wxWidgets

    Posté par  (site web personnel) . Évalué à 3.

    Moi je prendrais wxWidget. Je trouve l'API simple d'utilisation (aussi difficile que Qt disons) et extremement complete. En tout cas, j'éliminerai gtkmm car wx permet de compiler une appli en mode GTK... Et donc tu as le même résultat niveau look.
    Ensuite, je connais pas bien Qt... Pour la seule raison que je trouve ca très moche (le journal il dit de pas être objectif, me tapez pas :)) à part si c'est integré à KDE (que je trouve trop lourd)... Et puis pour finir, Qt est payant pour windows, donc je ne le trouve pas interessant.

    Pour finir d'appuyer le fait que je préfère wx, je dirais que l'avantage c'est que ca se compile avec le toolkit de la plateforme cible. (donc sous windows, ca ressemble a du windows, pas du GTK).. Et sous linux, ca ressemble a du motif, du GTK, du tout redéfini... (et du Qt si les mecs qui bossent dessus n'ont pas abandonné)

    Bon, et puis finalement y'a des environements comme wxGlade http://wxglade.sourceforge.net/(...) (génere du code python, c++, perl...)
    et la doc est très complète aussi : http://wxwidgets.org/docs.htm(...) et http://wxwidgets.org/hierarchy_stable.htm(...)

    Que demander de plus :)
    • [^] # Re: wxWidgets

      Posté par  . Évalué à 2.

      Pour la génération de code, c'est à éviter, il vaut mieux utiliser un equivalent a libglade (création de l'interface avec glade, sauvegarde dans un fichier xml). C'est plus propre au niveau du code.
  • # QT sans hésiter!

    Posté par  . Évalué à 4.

    Pour avoir beaucoup joué avec QT, je te le conseille!

    QT est beaucoup plus qu'un simple toolkit graphique, il peut aussi encapsuler tes communications avec le port série. Et là, adieu les select et autres read inbitables, bienvenue dans le monde de la programmation évenementielle.

    Et la doc est non seulement complète, mais aussi claire et accessible.

    Un pur bonheur.
    • [^] # Re: QT sans hésiter!

      Posté par  . Évalué à 1.

      Je suis assez d'accord avec JiBee, car selon moi :
      - QT n'est pas trop complique a apprendre,
      - il te permet de coder tres rapidement des petites applis,
      - tu gagnes du temps en utilisant les sur-couches permettant de faire de la prog au-dela du simple frontend, comme les sockets reseaux... Bien sur, cela devient plus risque si ton appli a de tres gros besoins de fiabilite en programmation systeme (ne pas s'amuser a coder un serveur en QT ou 500 postes sont susceptibles de se connecter ;-)
      • [^] # Re: QT sans hésiter!

        Posté par  (site web personnel) . Évalué à 2.

        Oui mais ces affirmations sont aussi vrai pour wx. Il s'agit bien plus qu'un simple toolkit graphique. Il y a tout pour la gestion réseau, des threads, timer, etc.... Donc cet argument n'a pas énormément de poid. De plus, le site de wx propose aussi wxBase qui est un sous ensemble de toutes l'api restreint à la couche non graphique.

        et niveau doc, je vois pas ce que Qt aurait de plus que wx.

        En fin de compte, je pencherai plutot pour dire que Qt et Wx, c'est la même chose... A la différence que wx me semble plus portable niveau licenses...

        Pour terminer, je viens de farfouiller la doc de Qt et un truc me choque un peu : il y a des classes QWindowsXPStyle, QMacStyle, ... pour choisir le look à utiliser. Cela ne me parait pas vraiment consistant. Sous wx, c'est exactement le même code quel que soit la plateforme destination, et ce n'est pas au programmeur de dire quel style employer, ca se passe au moment de la compilation.
      • [^] # Re: QT sans hésiter!

        Posté par  . Évalué à 3.

        ne pas s'amuser a coder un serveur en QT ou 500 postes sont susceptibles de se connecter ;-)


        A titre indicatif, le serveur auquel tu fais allusion est actuellement 100% stable... j'avais commis un grossière erreur qui m'aurait valu mon éxecution sommaire chez M$. Qt n'a rien à voir dans l'affaire.
    • [^] # Re: QT sans hésiter!

      Posté par  . Évalué à 2.

      J'ai effectivement trouvé une classe QextSerialPort, mais j'ai pas l'impression que ça permette de faire une fonction "OnSerialIncomingData" ( ou alors j'ai pas tout compris comment programmer sur le port série )
      • [^] # Re: QT sans hésiter!

        Posté par  . Évalué à 1.

        Pour faire ça il va te falloir un peu bidouiller...

        Tu crée un objet QFile qui agit sur le device de ton port série, et tu passes son handle() à un QSocketNotifier en lecture. Alors, tu auras un évenement activated() lors des arrivées de données.
  • # wx ...

    Posté par  (site web personnel) . Évalué à 2.

    Je fais beaucoup de WX avec python ... Il est vrai que tout y est (reseau, thread, gui, timers ...) ... Il manque qques trucs quand même (niveau son surtout) .....
    WX est très bien pour le côté portable (max/win/nux) ... tu ne touches presque rien ;-)
    L'api de WX est "pas très objet", par rapport à python, (tk ressemble plus à qqchose d'objet, par exemple) ... Mais un projet "wax" permet de faire du WX plus objet, plus python !
    Cependant, il faut savoir aussi, que tout n'est pas implémenté à fond, sur toutes les plateformes (ex: le wxlistctrl en mode virtuel+icon, ne fonctionne que sous win ... et pas sous nux ;-( )

    Pour avoir fait du GTK, avec php ;-) ... J'ai bien aimé, c'est déjà un peu plus objet ... (mais c'est assez lourd sous win ... mais nickel sous gnome) .. et c'est surtout libre, et très utilisé

    QT, j'en entends pas mal de bien, mais comme déjà dit plus haut ; ça ne m'interesse pas non plus ... déjà pk ce n'est pas libre sous windows (qt3) ... et aussi pk j'aime pas trop l'environement kde ... donc je crois que je n'y toucherai jamais

    Pour résumer, WX c'est vraiment le meilleur compromis pour du multi plateforme, sinon GTK s'en sort très bien pour le côté multi plateforme... et vraiment, si uniquement pour kde : QT
  • # mon avis à moi

    Posté par  (site web personnel) . Évalué à 2.

    wxWidgets a l'avantage d'être plus "portable", mais le fait de factoriser certains éléments, tu perds une partie du toolkit sous-jacent et c'est parfois bien dommage...
    Sinon entre Qt et GTK, choisi celui dont tu utilises le plus le desktop, cad KDE ou Qt.
    Dans tous les cas, quelque soit ton choix, arrange toi pour que ton appli ne dépende pas du toolkit graphique.
    • [^] # Re: mon avis à moi

      Posté par  (site web personnel) . Évalué à 3.

      tu ne parles pas de mes checkbox, quand même ! ;-)

      sinon :

      arrange toi pour que ton appli ne dépende pas du toolkit graphique.


      fera que, tu factoriseras, et du coup : tu perdras une partie du toolkit sous-jaccent ;-)

      et donc, autant utiliser WX, avec wxglade
      • [^] # Re: mon avis à moi

        Posté par  (site web personnel) . Évalué à 2.

        Tes checkbox sont un exemple parmis tant d'autre :)
        fera que, tu factoriseras
        ben non pas du tout, à partir du moment ou tu concoit ton application comme il faut, avec l'interface graphique parfaitement indépendante, je ne vois pas ce qui t'empêche après quand tu écris chaque interface pour chaque plateforme d'utiliser les particularités de chacune d'entre elles... En plus tu peux en profiter au passage pour respecter la charte graphique (pas seulement le look mais aussi la disposition, certains noms, etc. l'ergonomie quoi). wxWidgets c'est la solution du feignant.
        • [^] # Re: mon avis à moi

          Posté par  (site web personnel) . Évalué à 2.

          wxWidgets c'est la solution du feignant

          C'est mal ? L'utilisation de l'API permet quand même d'être plus consistant au niveau de la plateforme dans une certaine mesure car cela doit être implanté au niveau code de l'API.

          Toi qui est pro Mono, tu dois quand même bien être conscient de ces choses là justement.
          • [^] # Re: mon avis à moi

            Posté par  (site web personnel) . Évalué à 2.

            Toi qui est pro Mono, tu dois quand même bien être conscient de ces choses là justement.
            Oui mais non :-)
            Si tu prend le cas de Mono, la consistance au niveau de la plateforme intervient pourtout ce qui n'influence pas le comportement du programme et son intégration. Parcqu'on retrouve les même besoins sur toutes les plateformes, et souvent les même API avec souvent les mêmes interfaces.

            Le but de la plupart des portages, c'est avant tout de pouvoir utiliser une application dans un autre environnement, mais aussi de l'y intégrer. Et là il faut utiliser les particularités des environnements, car je ne connais aucun toolkit qui se paie le luxe d'être portable et de respecter la charte d'ergonomie de chaque environnement...Ca fait pour moi parti de la qualité d'un logiciel. Mono ne contredis pas du tout ce point de vu, puisqu'on retrouve Qt# et GTK# et les WinForms, pas de solution batarde à la Java à ses débuts.

            Tout ça pour dire que quand tu fais du portage, tu dois pouvoir tout porter ce qui est indépendant de l'environnement et tu devrais réécire l'intégration.

            PS : C'est un peu comme si les vendeurs de voitures ne prenait pas le temps de mettre le volant à droite quand ils vendent leurs modèles au Royaume-uni, même si la voiture roule très bien et que le client a les mêms fonctionnalités. Bah là c pareil. et wxWidget ne résoud qu'une partie du problème, la partie visuelle, mais pas l'ergonomie.
  • # Gtkmm

    Posté par  . Évalué à 4.

    Si tu veux du portable, sans hésiter Gtkmm (Qt sous windows est payant et pas libre). Sinon, si tu es sous KDE utilise QT/KDE et si tu es sous un environnement GTK utilise Gtkmm (et Gnomemm si tu es sous Gnome)... Histoire d'avoir une application qui colle avec ton environnement :)
    Du coté de wxWidgets, je ne l'aime pas du tout à cause de sa gestion merdique de l'UTF-8 (c'est une option de compilation, et si tu l'actives la classe wxString ne peut être contruite qu'à partir d'un wchar_t* et pas d'un char*. wxString hello = "Plop"; donne une erreur :/ ). Je ne l'ai testé qu'à l'époque où il s'appelait wxWindows, ça a peut être changé depuis...

Suivre le flux des commentaires

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