Reprise du message précédent :
0x90 a écrit :
Oui un petit peu mais c'est par usure, quand j'ai lut les tuto ils font une tartine la dessus, genre c'est une exclusivité alors que c'est un DP assez basique d'observer, en cours le profs à ressortit quasiment texto la même publicité élogieuse, et les 3/4 des personnes que j'ai croisé qui m'ont parlé de QT étaient tout excités et ne parlaient que de ça, principalement par méconnaissance des autres tk, c'est un poil fatiguant à la fin 
Tiré de la doc qt :
Citation :
Signals and slots are used for communication between objects. The signal/slot mechanism is a central feature of Qt and probably the part that differs most from other toolkits.
Older toolkits achieve this kind of communication using callbacks. A callback is a pointer to a function, so if you want a processing function to notify you about some event you pass a pointer to another function (the callback) to the processing function. The processing function then calls the callback when appropriate. Callbacks have two fundamental flaws. Firstly they are not type safe. We can never be certain that the processing function will call the callback with the correct arguments. Secondly the callback is strongly coupled to the processing function since the processing function must know which callback to call.
|
|
On est d'accord, ce DP est très répandu; il est aussi possible que les gens qui t'en ait parlé n'ai jamais testé (ou ne serait-ce que regarder) la libsig++ (au hasard 
). Personnellement, j'ai découvert Qt juste après les MFC, et en parallèle de wxWidgets, et sans connaître d'autres frameworks, donc j'en aurais aussi dit beaucoup de bien car je n'ai découvert de solution à base de templates que par la suite.
Un autre argument contre Qt qui revient souvent et le fait qu'ils aient développé leur -disons- QTL en recodant des conteneurs de la SL (j'en parle ici car, AMHA, c'est lié). Il y a à ça une raison toute précise: Trolltech veut que Qt soit utilisable sur une très grosse majorité des compilateurs. Y compris donc ceux sur lesquels une implémentation des template et/ou l'implémentation de la STL est/sont foireuse(s).
En fonctionnalité GUI pure que je n'ai pas trouvé dans la doc de gtkmm, ce sont les QAction. Avoir un objet commun pour créer/synchroniser les menus, les toolbars et la statusbar, je trouve ça extrémement pratique Il y a aussi la série des classes QGraphics* qui sont pas mal
Et hors GUI, mais lié au système Qt, le fait que les classes dérivant de QObject soit assez facilement utilisable par le biais de QSA et maintenant QtScript. On y ajoute les abstractions des liaisons au BdD, plus quelques fonctionnalités orientés systèmes (QDesktopServices, QLibrary ou encore le nouveau QFuture pour les systèmes concurrents pour ne citer qu'eux) et ça commence à peser lourd dans ma balance. Le résultat est un code assez cohérent si on utilise Qt à fond (au prix d'une dépendance monstrueuse qu'il faut accepter bien sûr).
Encore une fois, n'ayant pas utilisé gtkmm, il y a probablement des fonctionnalités qui y sont présentes, je ne vise pas à faire une quelconque comparaison qui donnerait lieu à un troll (mais si tu peux/veux me parler des avantages de gtkmm, j'en saurais davantage au sujet de cette lib 
)
0x90 a écrit :
Le fait qu'on ne puisse pas allouer un widget dans la pile par exemple. (Après quand à savoir si c'est vraiment essentiel, c'est une question plus personelle... mais j'aime bien avoir ce choix)
|
Ce n'est pas qu'on ne peut pas, c'est qu'il faut le faire dans des cas bien précis, dû à des relations hiérarchiques. Personnellement, j'ai compris et accepté cette méthode, mais il est vrai que c'est une affaire de goûts et de couleurs aussi 
edit: orthographe...
FORUM HardWare.fr
