Il y a vraiment deux approches différentes entre WxWidget et Qt.
Qt émule le look'n feel des contrôles des différentes environnements. Donc un ComboBox Qt par exemple, est avant-tout un combo-box écrit par Qt en C++, et un certain nombre de ses comportements sont adaptés selon la plate-forme.
WxWidget au contraire, se targue d'utiliser les contrôles natifs de la plate-forme cible. Donc en théorie, en combo-box en WxWidget sous Windows, c'est un combo-box de Windows, sous MacOs, c'est l'OS qui fourni le combo-box, etc etc.
Dans la théorie, ça crée une émulation plus fidèle des contrôles de la plate-forme, mais au risque de d'introduire des bugs qui sont spécifiques à la plate-forme à cause de comportements légèrement différents d'une plate-forme à l'autre. Un autre inconvénient, c'est qu'on se retrouve vite à faire du nivellement par le bas: telle plate-forme ne fournit pas un contrôle donné, donc soit Wx ne le fournit pas, soit Wx doit l'émuler et prend la même démarche que Qt, faire un codage interne. J'ai vu traîner dans la documentation ce genre de cas mais j'ai plus d'exemples en tête.
Au final, il me semble que WxWidget fournit pas mal de Widget maison (approche à la Qt) et des widgets natifs uniquement pour les contrôles de base. Et surtout, sur un certains nombre de plate-forme, c'est plus vraiment les widgets natifs qui sont utilisés. Les explication sur MacOs me font supposer que sous MacOs, c'est en fait le port Gtk qui est utilisé et non pas les widget natifs Cocoa mais je m'avance.
En tout cas, en Python, c'est un des GUI les plus populaires (loin devant PyQt il me semble).
[^] # Re: je n'ai jamais utilisé wxWidgets
Posté par Philippe F (site web personnel) . En réponse à la dépêche wxWidgets 3.0. Évalué à 10.
Il y a vraiment deux approches différentes entre WxWidget et Qt.
Qt émule le look'n feel des contrôles des différentes environnements. Donc un ComboBox Qt par exemple, est avant-tout un combo-box écrit par Qt en C++, et un certain nombre de ses comportements sont adaptés selon la plate-forme.
WxWidget au contraire, se targue d'utiliser les contrôles natifs de la plate-forme cible. Donc en théorie, en combo-box en WxWidget sous Windows, c'est un combo-box de Windows, sous MacOs, c'est l'OS qui fourni le combo-box, etc etc.
Dans la théorie, ça crée une émulation plus fidèle des contrôles de la plate-forme, mais au risque de d'introduire des bugs qui sont spécifiques à la plate-forme à cause de comportements légèrement différents d'une plate-forme à l'autre. Un autre inconvénient, c'est qu'on se retrouve vite à faire du nivellement par le bas: telle plate-forme ne fournit pas un contrôle donné, donc soit Wx ne le fournit pas, soit Wx doit l'émuler et prend la même démarche que Qt, faire un codage interne. J'ai vu traîner dans la documentation ce genre de cas mais j'ai plus d'exemples en tête.
Au final, il me semble que WxWidget fournit pas mal de Widget maison (approche à la Qt) et des widgets natifs uniquement pour les contrôles de base. Et surtout, sur un certains nombre de plate-forme, c'est plus vraiment les widgets natifs qui sont utilisés. Les explication sur MacOs me font supposer que sous MacOs, c'est en fait le port Gtk qui est utilisé et non pas les widget natifs Cocoa mais je m'avance.
En tout cas, en Python, c'est un des GUI les plus populaires (loin devant PyQt il me semble).