56Fermer58
Kevin KoflerLe 27/08/2008 à 02:07
Flanker (./55) :
Si le logiciel est bien fichu, l'interface graphique n'est qu'une couche bien séparée du reste du code et simple à changer embarrassed

Facile à dire en théorie, l'as-tu essayé en pratique? Romain a essayé cette stratégie avec TiLP, verdict: beaucoup trop d'effort à maintenir pour essentiellement aucun gain, et il est repassé à GTK+ partout.
Brunni (./56) :
Quand je parle de cohérence c'est par exemple le fait qu'une appli KDE s'intègre si mal sous GNOME alors qu'en termes de fonctionnalités elle est identique.

Bah, j'utilise des applications GNOME de temps en temps (et XChat (qui est une application GTK+ non-GNOME) en permance) sous KDE, ça marche plutôt bien. Il y a quelques trucs agaçants:
* les dialogues de fichiers GTK+ sick,
* les boutons ordonnés à l'envers (GTK+ propose une fonction pour avoir le bon ordre sous KDE, mais il faut spécifier l'ordre à la main pour chaque dialogue et pas grand monde ne l'utilise),
* le manque d'options,
mais c'est loin d'être la catastrophe dont tu parles. (Cela dit, à part pour XChat que j'adore à cause de l'extensibilité par des plugins C, qui propose de nombreuses options contrairement aux applications GNOME et dont j'utilise rarement les dialogues (donc les problèmes de dialogues de fichier et de boutons ne dérangent pas trop), je préfère en général les alternatives KDE quand elles existent et proposent à peu près les mêmes fonctionnalités.)
Un autre exemple est que des applis aient le look & feel de GNOME/Mac sous Windows, en tous cas quand ça n'apporte rien à quelqu'un d'habitué à Windows (à part la déroute).

Euh, quelles sont les applications avec le look&feel de GNOME? GTK+ essaie au contraire de bien s'intégrer (cf. le thème GTK-Wimp qui a été intégré à GTK+ dans les versions récentes).
En plus quand tu fais tout toi-même il y aura TOUJOURS des choses que tu n'auras pas implémentées ou pas aussi bien que celles du système (qui si ça se trouve ont été améliorées depuis), du coup des gens seront mécontents. Et en particulier si ton soft est multiplate-forme: même si un bureau GNOME peut sembler très similaire à un bureau Windows, il y a quand même énormément de petites différences qui comptent beaucoup à quelqu'un d'habitué. Le système est censé te permettre d'en faire abstraction, mais si tu préfères tout faire toi-même, ben va falloir accepter les problèmes de cohérence inutiles...

Mais OO.o essaie au contraire de s'intégrer aux différentes plateformes en utilisant leurs routines d'affichage des contrôles, cf. le Native Widget Framework (et je signale à ceux qui n'ont pas encore essayé une version récente de OO.o que ces captures d'écran sont de 2004, il y a eu des améliorations depuis). Cette stratégie (afficher avec les fonctions natives, mais gérer le comportement en interne avec du code multiplateforme) a aussi été choisie (en plus du NWF OO.o sus-cité) par GTK+, Qt, XUL (Firefox etc.), Swing (mais ils utilisent un look&feel non natif par défaut pour je ne sais pas quelle raison, peut-être du marketing, comme le look Aqua de Safari, mais ça fait que les applications Swing ont un look hors de place par défaut alors que ce ne serait pas du tout nécessaire! sad) etc., et ce parce que ça a de nombreux avantages par rapport à la stratégie alternative (wrapper entièrement les contrôles natifs) choisie par wxWidgets et SWT. Notamment:
* les applications ne dépendent pas des bogues, des limitations arbitraires et des comportements bizarres des contrôles natifs de chaque plateforme. (Savais-tu par exemple que les champs texte de 9x/Me ne géraient pas du tout l'Unicode?)
* les mêmes fonctionnalités sont disponibles partout, tu n'es pas limité au "dénominateur commun" et tu peux être sûr que si tu utilises une certaine fonctionnalité du contrôle (par exemple automatiquement remplacer l'intérieur d'un label par des points de suspension plutôt que tronquer bêtement tout ce qui dépasse à droite), elle fonctionnera sur toutes les plateformes supportées, pas seulement celles où le contrôle natif propose cette fonctionnalité.
* la performance peut être meilleure que celle des contrôles natifs sous certains OS.
* on ne doit pas se taper un toolkit par dessus un autre toolkit sous X11 qui n'a pas de toolkit natif (alors que wxWidgets et SWT passent par GTK+, ce qui fait un toolkit multiplateforme par dessus un autre toolkit multiplateforme).
Les désavantages sont que le toolkit doit faire un effort particulier pour s'intégrer au niveau feel, pas seulement look, et que ce n'est pas toujours fait impeccablement, et dans une certaine mesure aussi que le code est plus grand parce que ça prend de la place de recoder ce qui est déjà présent dans le système.