Le problème de WxWidget, outre le fait que le projet s'est quand même pris une bonne claque de vétusté, il traine pas mal de bug qui sont spécifiques à la plate-forme.
En fait, les toolkits natifs sont sans surprise hyper spécifique à leur plate-forme. Et les unifier derrière une interface unique, ça marche pas complètement. Tu tombes très vite sur des comportements spécifiques à une plate-forme, qui sont buggés sous une autre et très pénible à débugger car le chemin emprunté par le code n'est pas identique. Surtout que l'idée d'avoir une interface unique, c'est justement de moins passer de temps sur les spécificités des plateformes.
En fait, ce concept de toolkit d'interface graphique universelle est un problème très difficile à résoudre alors qu'il parait simple au départ. Pour un bouton, on croit déjà être capable de résoudre le problème alors que déjà c'est difficile: thèmes de l'OS, placement des boutons dans un dialogue (MacOs X et Windows ont des conventions opposés pour l'ordre du OK/Cancel), etc. Par exemple, sous Windows, j'ai activé l'option "placer le pointeur automatiquement sur le bouton par défaut". Il y a bien la moitié des applications qui ne le font pas (dont Qt si je me souviens bien) parce qu'ils n'utilisent pas les API de l'OS. Mais même sur des dialogues système de Windows, ça ne marche pas bien car ceux-là aussi sont à moitié customisés.
Qt s'en sort pas trop mal bien qu'il soit régulièrement critiqué pour cela.
Il faut voir aussi que pour les fournisseurs d'OS graphiques payant (la Poire croquée et la Porte fermée, je crois que c'est leur nom ?), l'interface graphique, c'est le lien direct avec l'utilisateur. Donc quand ils font une version majeure de leur OS, ils ont évidemment envie de montrer que c'est plus cool, plus fluide, plus joli, plus dans l'air du temps et ils vont a minima refaire un style pour leurs contrôles graphiques, et/ou refaire des API pour utiliser les dernières fonctionnalités de l'OS.
C'est un travail assez colossal de suivre ces évolutions dans un toolkit qui n'utilise pas l'API natif de l'OS. Et même pour un toolkit qui les utilise car il y a des nouvelles API qui apparraissent. D'autant que chaque OS a plusieurs API et styles graphiques, donc tu as à peine fini de polir le style précédent pour qu'il ressemble bien au natif qu'il faut reprendre le travail pour la nouvelle version.
Qt a maintenant des ressources plus conséquentes et arrive mieux que par le passé à suivre ce type d'évolutions. Mais il y a toujours un décalage.
Pour un toolkit qui repart de zéro comme Slint, je suis extrêmement confiant qu'ils n'arriveront pas à suivre les styles natifs des OS dans le temps. Ça n'enlève rien à la valeur du projet, il faut juste pas imaginer que ce sera facile ou réalisable d'être "comme le toolkit natif".
[^] # Re: Ce n'est pas du natif
Posté par Philippe F (site web personnel) . En réponse à la dépêche Slint 1.0 : une boîte à outils graphiques natifs pour poste client et embarqué. Évalué à 10.
Le problème de WxWidget, outre le fait que le projet s'est quand même pris une bonne claque de vétusté, il traine pas mal de bug qui sont spécifiques à la plate-forme.
En fait, les toolkits natifs sont sans surprise hyper spécifique à leur plate-forme. Et les unifier derrière une interface unique, ça marche pas complètement. Tu tombes très vite sur des comportements spécifiques à une plate-forme, qui sont buggés sous une autre et très pénible à débugger car le chemin emprunté par le code n'est pas identique. Surtout que l'idée d'avoir une interface unique, c'est justement de moins passer de temps sur les spécificités des plateformes.
En fait, ce concept de toolkit d'interface graphique universelle est un problème très difficile à résoudre alors qu'il parait simple au départ. Pour un bouton, on croit déjà être capable de résoudre le problème alors que déjà c'est difficile: thèmes de l'OS, placement des boutons dans un dialogue (MacOs X et Windows ont des conventions opposés pour l'ordre du OK/Cancel), etc. Par exemple, sous Windows, j'ai activé l'option "placer le pointeur automatiquement sur le bouton par défaut". Il y a bien la moitié des applications qui ne le font pas (dont Qt si je me souviens bien) parce qu'ils n'utilisent pas les API de l'OS. Mais même sur des dialogues système de Windows, ça ne marche pas bien car ceux-là aussi sont à moitié customisés.
Qt s'en sort pas trop mal bien qu'il soit régulièrement critiqué pour cela.
Il faut voir aussi que pour les fournisseurs d'OS graphiques payant (la Poire croquée et la Porte fermée, je crois que c'est leur nom ?), l'interface graphique, c'est le lien direct avec l'utilisateur. Donc quand ils font une version majeure de leur OS, ils ont évidemment envie de montrer que c'est plus cool, plus fluide, plus joli, plus dans l'air du temps et ils vont a minima refaire un style pour leurs contrôles graphiques, et/ou refaire des API pour utiliser les dernières fonctionnalités de l'OS.
C'est un travail assez colossal de suivre ces évolutions dans un toolkit qui n'utilise pas l'API natif de l'OS. Et même pour un toolkit qui les utilise car il y a des nouvelles API qui apparraissent. D'autant que chaque OS a plusieurs API et styles graphiques, donc tu as à peine fini de polir le style précédent pour qu'il ressemble bien au natif qu'il faut reprendre le travail pour la nouvelle version.
Qt a maintenant des ressources plus conséquentes et arrive mieux que par le passé à suivre ce type d'évolutions. Mais il y a toujours un décalage.
Pour un toolkit qui repart de zéro comme Slint, je suis extrêmement confiant qu'ils n'arriveront pas à suivre les styles natifs des OS dans le temps. Ça n'enlève rien à la valeur du projet, il faut juste pas imaginer que ce sera facile ou réalisable d'être "comme le toolkit natif".