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(...)
)
Journal Choix toolkit C/C++ : gtk[mm] vs wxWidgets vs Qt
25
mai
2004
# Choix toolkit C/C++ : gtk[mm] vs wxWidgets vs Qt
Posté par kruskal . Évalué à 3.
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 Alex . Évalué à 2.
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 Nicolas Antoniazzi (site web personnel) . Évalué à 3.
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 Guillaume Chevallereau . Évalué à 2.
# QT sans hésiter!
Posté par Jean-Baptiste Mayer . Évalué à 4.
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 MeJohn . Évalué à 1.
- 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 Nicolas Antoniazzi (site web personnel) . Évalué à 2.
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 Jean-Baptiste Mayer . Évalué à 3.
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 farib . Évalué à 2.
[^] # Re: QT sans hésiter!
Posté par Jean-Baptiste Mayer . Évalué à 1.
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 manatlan (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 manatlan (site web personnel) . Évalué à 3.
sinon :
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 TImaniac (site web personnel) . Évalué à 2.
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 Nicolas Antoniazzi (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 2.
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 Moonz . Évalué à 4.
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.