Discussion :

[yan]

oui j'aimerais bien que tu detailles les problemes que tu rencontres...
C'est inestimable d'avoir du retour d'experience de quelqu'un qui le manipule tous les jours ... merci d'avance pour ton feedback.

+1
ça m'intéresser aussi

[dtrosset]

Bonjour,

Je l'utilise aussi au boulot, et au final je n'aime pas forcément.
J'aime :

• C'est cross platform. Vraiment ! Win, Linux, Mac.
• L'API est *assez* cohérente.

Je n'aime pas :

• La phase de pré-compliation (moc et uic) est lourdingue à gérer dans les projets et les makefiles, malgré leur make maison (qmake).
• Tant qu'on ne fait qu'utiliser les widgets pas trop de problèmes. Mais dès qu'on dérive ou qu'on assemble beaucoup de widgets ensemble, on a tout de suite des problèmes d'affichage, de layout, de glitches, lors des changements de version. (Un peu comme avec les changements de version de Java : il vaut toujours mieux exécuter sur la même version que celle sur laquelle on a développé).
• Qt a énormément grossi. Ce n'est plus une librairie pour UI, c'est un framework complet d'abstraction d'OS. Et en ce qui concerne les widgets UI, pas grand chose de nouveau qui aide vraiment depuis bien longtemps. Qt a beaucoup grossi ... sur le tout le reste en fait, pas sur l'UI.

Au final, je suis toujours à la recherche de quelque chose d'autre pour des projets personnels. Et j'ai le même problème avec Python : tkInter, PyQt ou PyWidgets ?

[epsilon68]

[*]Tant qu'on ne fait qu'utiliser les widgets pas trop de problèmes. Mais dès qu'on dérive ou qu'on assemble beaucoup de widgets ensemble, on a tout de suite des problèmes d'affichage, de layout, de glitches, lors des changements de version. (Un peu comme avec les changements de version de Java : il vaut toujours mieux exécuter sur la même version que celle sur laquelle on a développé).

finalement on ne retrouve pas ce sentiment avec tous les toolkits?
j'en ai eu une tonne de probleme avec Java, VB, .NET ...
J'ai l'impression de Qt est beaucoup plus souple et robuste... mais je ne l'utilise pas professionnellement, donc c'est pour ca que le feedback de MAT007 m'interessait beaucoup.

Qt evolue aussi beaucoup sur les widgets... en fait ils font la transition vers les effets graphiques et j'imagine qu'il y a plein de remise en cause partout dans leur code... Ca ne se passera pas sans douleur à mon avis.

[Luc Hermitte]

ASL me plait beaucoup pour diverses raisons (pas autant de NIH qu'ailleurs, mais bâtie autour de la SL+Boost+TBB ; descriptif ; pleins de papiers super intéressants ; etc), en jouant avec adobe.begin, j'ai vite été convaincu par les possibilités de la bibliothèque.

Par contre il lui manque un certain nombre de choses pour pouvoir l'utiliser sereinement en production.

[lezurp]

Quelqu'un aurai t'il un feedback sur fltk ?? compliqué ? simple ?? vraiment portable ?

ASL je ne connais pas du tout , par contre je ne trouve pas de screenshot,
il me semble qu'il faille installer une machine virtuel . faut t il l'installer comme une machine virtuel java ( avant de fournir mon application ?) ou est t il possible de fournir mon application avec la machine virtuel. Et je n ai rien trouve non plus concernent la portabilité ( peu etre ai je mal lu , mais je n ai rien vue)

epsilon68 tu l a acheté personellement QT ? Ca t'a couté combien ??
tu a droit a des mise a jour ??

[Luc Hermitte]

Pas besoin de machine virtuelle pour ASL. Et c'est portable au moins sur mac, windows et linux.
Tu peux commencer par récupérer adobe.begin sur le site de la bibliothèque et déjà jouer avec. Prototyper de nouvelles interfaces, etc.

Après si tu veux t'en servir dans tes propres projets, il faudra installer la bibliothèque comme n'importe quelle autre -- au détail qu'elle impose une installation de boost et de TBB un chouilla particulière.

[epsilon68]

epsilon68 tu l a acheté personellement QT ? Ca t'a couté combien ??
tu a droit a des mise a jour ??

oui je l'ai acheté personnellement,
contactes sales@trolltech.com pour avoir le detail des prix etc.
quand tu achetes Qt tu as droit pour 1 an de support et de mise a jour,
a renouveler tous les ans pour recevoir les nouvelles mise a jours.

[epsilon68]

au détail qu'elle impose une installation de boost et de TBB un chouilla particulière.

je crois que c'est ca que j'aime chez Qt, compilation et installation et utilisation hyper facile.
concernant le NIH, je pense (et je serais d'accord) qu'ils veulent controller 100% leur code...

[JolyLoic]

Qu'ils veuillent être indépendants de TBB, par exemple, ça peut se comprendre. Mais la plupart des choses qu'ils redéfinissent sont des aspects de la STL. Et là, je suis moins d'accord.

Pour boost, c'est intermédiaire. Ne serait-ce que par la license très permissive. Je ne serais pas hyper choqué qu'ils imposent par exemple une dépendance à une version non à jour de boost.

Il n'empêche qu'à l'heure actuelle, c'est probablement Qt que je choisirais, faute de mieux en terme d'achèvement.

[yan]

• La phase de pré-compliation (moc et uic) est lourdingue à gérer dans les projets et les makefiles, malgré leur make maison (qmake).

Ben justement le qmake fait tout. Il fait même les projets pour visual.
Tu as juste à garder à jour le .pro
Je ne voies pas ce qui est lourdingue ?

• Tant qu'on ne fait qu'utiliser les widgets pas trop de problèmes. Mais dès qu'on dérive ou qu'on assemble beaucoup de widgets ensemble, on a tout de suite des problèmes d'affichage, de layout, de glitches, lors des changements de version. (Un peu comme avec les changements de version de Java : il vaut toujours mieux exécuter sur la même version que celle sur laquelle on a développé).

Enfin ça c'est beaucoup stabilisé maintenant. La version 4 as subit beaucoup de changement, de découpage, ... et donc de problème de se genre...

• Qt a énormément grossi. Ce n'est plus une librairie pour UI, c'est un framework complet d'abstraction d'OS. Et en ce qui concerne les widgets UI, pas grand chose de nouveau qui aide vraiment depuis bien longtemps. Qt a beaucoup grossi ... sur le tout le reste en fait, pas sur l'UI.

Qt fournie beaucoup de chose et on fait un énorme effort pour tout séparer.
GTK et WxWidget sont aussi énorme!!!!
Qu'es ce qu'il te manque qui pourrais vraiment t'aide ???

Pour moi le gros avantage de Qt est qu'il est soutenue par une grosse communauté (KDE) et une industrie (Nokia). Y as donc la qualité du monde OpenSource et du monde industriel.

Puis franchement, Qt forme un tout très cohérent, robuste et qui s'interface très bien. Le point le plus fort pour moi se situe au niveau des signal/slot entre thread. Je n'ai pas vue d'équivalent en terme de qualité.

[lezurp]

bon apres tout ca j esite entre QT et wxwidget.

la reponce de qt pour le prix va bien sur peser...(surtout pour un devellopement perso pour lequel je n ai pas envie de donner mes sources).

Mais j aimerai quand meme avoir des avis sur fltk...

merci a tous

[loufoque]

Pourquoi as-tu choisi de rejeter GTK+ ?
La version C++, GTKmm, est plutôt élégante. Et la licence est permissive.

[lezurp]

j ai ecarté gtkmm bien que la licence me convienne parfaitement, et qu il semble possible de changer de theme :

car il semble que pour pouvoir porter mon application d'une machien a une autre je dois fournir en certain nombre de dll pas sans avoir la garantie de focntionner pour autent dans tout les cas. contrairement a qt ou wxwidget, ou apparament 2 3 dll suffisent pour assurer un bon fonctionnement. je n ai pas vraiemnt envie de jouer avec ca.

[loufoque]

Qt et GTK+ fonctionnent sous Windows avec le même principe.
Aucun des deux ne fait utilisation de l'API de windows.

Les deux devraient avoir un nombre comparable de DLLs, et GTK+ c'est plutôt plus léger que Qt...

[epsilon68]

on ne peut pas vraiment comparer GTK+ et Qt
Qt fonctionne parfaitement sur Windows et MacOSX
GTK+ n'existe pas sur Mac et n'est pas vraiment supporté sur Windows

[yan]

Qt et GTK+ fonctionnent sous Windows avec le même principe.
Aucun des deux ne fait utilisation de l'API de windows.

Qt si.
http://qt.developpez.com/doc/latest/...e.html#details

We provide one paint engine for each window system and painting framework we support. This includes X11 on Unix/Linux and CoreGraphics on Mac OS X

Les deux devraient avoir un nombre comparable de DLLs, et GTK+ c'est plutôt plus léger que Qt...

De base, pour une ihm en Qt tu n'as besoin que de deux dll QtCore et QtGui.

[zais_ethael]

Je n'ai pas dit que GTK ne fonctionnerait pas en fournissant les dll, c'est juste que ce n'est pas la méthode préconisée par les fournisseurs des binaires.
Pour bien faire il faut installer GTK+ et gtkmm (deux packages séparés si je me souviens bien, avec chacun leurs compléments glade) en lançant leurs installateurs, exactement comme on est généralement obligé de le faire avec des langages à VM comme Java, dotnet, etc...
Bref c'est un problème de solution de déploiement. Ca devient tout un art ce truc, pas étonnant que les licences InstallShield soient aussi chères.

@loufoque: tu n'es pas obligé de me croire, mais si, GTK est vraiment fort lourd (on se demanderait ce qu'ils mettent dans leurs dlls).

[loufoque]

Qt comme GTK+ n'utilise pas les widgets Windows.
Ils demandent à Windows une fenêtre, puis ils peignent dessus leur propre truc, en essayant sous Windows de faire un truc qui ressemble aux widgets natifs.

Ce que tu cites, Mongaulois, ne fait que confirmer ce que je dis.

[epsilon68]

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

[yan]

Qt comme GTK+ n'utilise pas les widgets Windows.

Ha ça oui.
Par contre Qt utilise des styles qui sont natif à certaine plateforme
http://qt.developpez.com/doc/latest/...e.html#details

Warning: This style is only available on the Windows XP platform because it makes use of Windows XP's style engine.

http://qt.developpez.com/doc/latest/...e.html#details

Warning: This style is only available on Mac OS X because it relies on the HITheme APIs.

et pour GTK dans la prochaine version.

Il fait donc plus qu'essayer de ressembler. Il demande comment faire