Ah, les boutons OK et Cancel inversés entre Gnome et KDE, ça faisait bien 5 ans qu'on en avait pas parlé !
Autant sur le fait de cliquer sur le bas de la barre de défilement, ou ne pas supporter le F2 pour renommer des fichiers et F5 pour rafraîchir la fenêtre, je comprends. Autant, le Ok / Cancel, je trouve ça ridicule.
Tout ça pour dire qu'il y a des règles d'interfaces graphique pour chaque OS
Règles d'interfaces qui sont copieusement ignorés par un nombre incalculable d'applications, en particulier des applications à très gros succès, ou encore des applications qui sont pourtant promues par les fabricants de l'OS.
Il n'y a qu'à prendre les versions récentes de Office, qui jurent complètement avec les autres applications développées sous Windows XP grâce à la nouvelle bande de raccourcis qui renvoie aux oubliettes le concept de menu.
Donc les règles d'UI, c'est pas ça qui va m'empêcher de choisir un toolkit générique plutôt qu'un toolkit natif. Notamment parce que si un utilisateur veut utiliser mon application, c'est pas la position des boutons Cancel / Ok qui l'empêchera de le faire, ou les autres fioritures liées à l'intégration profonde dans un OS.
En ce qui me concerne, entre supporter un OS avec un look'n feel et comportement raisonnable grâce à un toolkit générique, et ne pas supporter l'OS en question parce qu'il faudrait recoder l'application dans le toolkit natif pour ce faire, mon choix est vite fait.
Honnêtement, des intégriste de l'UI, il y en a. Ceux qui repèrent que l'application est en fait Qt native et pas MacOs à cause de l'espacement entre les menu n'est pas bon et quand on fait un racourci clavier précis, ca ne fait pas ce qu'il faut. Ok, ils ont le droit de protester. Mais je pense d'une part que cela ne constitue qu'une part mineure de la base d'utilisateurs, d'autre part que la plupart des problèmes soulevés peuvent être adressés avec le temps et l'expérience, si l'application a du succès.
Je doute d'arriver un jour où la seule évolution qui reste à faire pour une application soit de permuter les boutons Ok / Cancel, et que toutes les autres demandes et bugs aient été satisfaits…
Pour reprendre une maxime de Python: Practicality beats Purity.
[^] # Re: Les toolkits portables
Posté par Philippe F (site web personnel) . En réponse au journal Le développement en natif pour un soft universel ?. Évalué à 7.
Ah, les boutons OK et Cancel inversés entre Gnome et KDE, ça faisait bien 5 ans qu'on en avait pas parlé !
Autant sur le fait de cliquer sur le bas de la barre de défilement, ou ne pas supporter le F2 pour renommer des fichiers et F5 pour rafraîchir la fenêtre, je comprends. Autant, le Ok / Cancel, je trouve ça ridicule.
Règles d'interfaces qui sont copieusement ignorés par un nombre incalculable d'applications, en particulier des applications à très gros succès, ou encore des applications qui sont pourtant promues par les fabricants de l'OS.
Il n'y a qu'à prendre les versions récentes de Office, qui jurent complètement avec les autres applications développées sous Windows XP grâce à la nouvelle bande de raccourcis qui renvoie aux oubliettes le concept de menu.
Donc les règles d'UI, c'est pas ça qui va m'empêcher de choisir un toolkit générique plutôt qu'un toolkit natif. Notamment parce que si un utilisateur veut utiliser mon application, c'est pas la position des boutons Cancel / Ok qui l'empêchera de le faire, ou les autres fioritures liées à l'intégration profonde dans un OS.
En ce qui me concerne, entre supporter un OS avec un look'n feel et comportement raisonnable grâce à un toolkit générique, et ne pas supporter l'OS en question parce qu'il faudrait recoder l'application dans le toolkit natif pour ce faire, mon choix est vite fait.
Honnêtement, des intégriste de l'UI, il y en a. Ceux qui repèrent que l'application est en fait Qt native et pas MacOs à cause de l'espacement entre les menu n'est pas bon et quand on fait un racourci clavier précis, ca ne fait pas ce qu'il faut. Ok, ils ont le droit de protester. Mais je pense d'une part que cela ne constitue qu'une part mineure de la base d'utilisateurs, d'autre part que la plupart des problèmes soulevés peuvent être adressés avec le temps et l'expérience, si l'application a du succès.
Je doute d'arriver un jour où la seule évolution qui reste à faire pour une application soit de permuter les boutons Ok / Cancel, et que toutes les autres demandes et bugs aient été satisfaits…
Pour reprendre une maxime de Python: Practicality beats Purity.