Philippe F a écrit 2204 commentaires

Pourquoi tu utilises PySide plutôt que PyQt ? Et pourquoi tu as besoin de compiler quoi que ce soit puisque tu fais du Python ? Tu m'interpelles là…

J'ai bien évidemment un a priori hyper favorable pour Qt, et ceux qui lisent les trolls sur Gnome et KDE depuis quelques années sur linuxfr doivent le savoir. Après, il est toujours bon de vérifier ses a priori, surtout sur un domaine où j'y connais queud comme le développement mobile.

J'oubliais le lien magique pour trouver les softs que j'utilise sous Windows:
http://www.freehackers.org/Surviving_on_Windows

Il reste un problème que je n'ai pas résolu: impossible d'avoir un terminal UTF8 avec Console. Même en bidouillant les polices Windows, c'est pas possible.

Je reconnais bien mon parcours. Après quelques années où je ne suis plus que sous Windows, j'ai opté pour les choix suivants (qui ne sont pas universels mais que marchent pour moi):

1. Mon terminal, c'est Console. Un programme plus maintenu mais qui marche hyper bien.

2. Mon shell, c'est cygwin bash.

3. Je privilégie tout ce qui existe en natif vis à vis des versions cygwin. Ca veut dire que j'ai un gcc msys, un mercurial, un python, un vim qui sont des installations natives sous Windows. J'ai volontairement désinstallé le gcc et le python de cygwin pour être sur de ne jamais l'utiliser par erreur.

4. J'ai un répertoire d:/program où je colle tous mes programmes Windows pseudo-unix et un répertoire d:/program/utils qui est dans mon PATH.

5. Dans mon d:/program/utils, j'ai des lanceurs en .bat et .sh pour les programmes que j'utilise le plus souvent. Quelques programmes comme mercurial ont droit de cité dans mon PATH. Et quelques alias pour appeler automatiquement mes .sh

6. Certains trucs sont tout simplement incompatible avec Cygwin. Typiquement, si je dois compiler un projet Qt sous CMake, je lance un cmd avant de faire quoi que ce soit. Sinon, CMake se goure.

7. J'ai un gvim.sh qui prend des chemins de fichiers au format cygwin et les convertit en format windows pour gvim. Ca me permet de faire des grep -r . "toto" -l | xargs gvim.sh

Donc globalement une grosse usine à gaz, sauf que avec le temps, ça marche très bien.

Quant à PySide, j'ai jamais essayé. Je préfère rester fidèle à Phil Thompson qui fait un travail irréprochable sur PyQt depuis aussi longtemps que Qt 1.4 existe si je me souviens bien.

Le déploiement Qt sous Windows, je l'ai toujours vécu comme trivial. Le code travaillant avec Qt est réellement portable, donc à part quelques petites windowseries au niveau du compilateur (qui ont tendance à disparaître avec le temps), tu génères ton appli sous Windows en moins d'une journée même si tu n'y connais rien.

Et, à partir de ton .exe, tu te bricoles vite-fait un petit installeur à coup de InnoSetup (je recommande) ou NSIS (pour les malades mentaux). Il y a même Wix, projet open source de Microsoft pour générer des .msi tous beaux tous propres (j'ai jamais testé. Ça prend aussi moins d'une journée, voire moins d'une heure. Bien sur, tu embarques toutes les DLL de Qt que tu utilises dans ton installeur, pour éviter toute source de conflit à la con. L'installeur les trouve en général tout seul, et elles se nomment toutes QtQuelque chose.

Pour définir l'icone de ton application, c'est pas comme sous x11, il faut fournir un .ico que n'importe quel logiciel de dessin te génerera en 3 secondes à partir d'un png. Le .ico doit être embarqué dans ton .exe mais c'est très facile à mettre en place.

Et voilà, tu as un package installable sur toutes les versions de Windows. Après, il peut y avoir des subtilités 32 bits vs 64 bits, ou bien l’application doit demander des droits Windows pour s'exécuter, ou bien il faut lire 5 minutes de doc pour comprendre où stocker tes fichiers utilisateurs. Mais globalement, ça marche bien et de façon fiable.

Idem pour Python + PyQt + py2exe ou pyinstaller.

Ah si, si tu veux linker Qt en static sous Windows, il me semble que ce n'est plus possible.

Disclaimer: c'est mon expérience, j'ai jamais écrit de programmes utilisés par des milliers de gens. Mais justement, pour un développeur dilettante, le temps économisé en passant par Qt est précieux.

Pour Gtk, j'ai jamais expérimenté moi-même mais j'ai ouie dire beaucoup de mal de gens qui avaient fait une application Gtk et envisageaient une version Windows. J'ai vu passer d'ailleurs des applications Gtk dont la version Windows n'est plus développée car trop difficile à maintenir, ou bien qui gardent sciemment une ancienne version de Gtk pour pouvoir facilement garder la portabilité.

Et en tant qu'utilisateur, j'ai eu quelques conflits d'applications Windows Gtk qui essayaient plus ou moins de partager leur installation de Gtk donc on va dire que je serre les fesses quand je vois du Gtk sous Windows.

Je suis content de savoir que Gtk reprend la route de Windows. Vu la réputation qu'il se sont fait, il va y avoir du travail. Et surtout, il va falloir de l’énergie pour maintenir ce port. Si je me souviens bien, un des problèmes de Gtk sous Winsows, c'est le nombre colossal de dépendance de Gtk, qui complique singulièrement la tâche. Qt de par sa nature plus monolitique est moins embêtée.

Pour WxWidget, tu confirmes ce que j'ai entendu dire. A part les anciens programmeurs MFC, j'ai l'impression qu'il n'y a pas beaucoup de gens pour dire du bien de WxWidgets.

Euh, perso, je juge pas le niveau d'intuitivité d'un OS à la longueur des URL pour accéder à sa documentation. Toi si ?

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.

J'ai lu un peu la doc en diagonal, ça me plait bien. Ca réutilise un nombre incalculable de briques python qui marchent bien depuis des années (PyGame, PIL, PyCairo, …), et package tout ça dans un framework orienté python.

Contrairement donc à Qt qui étant basé sur du C++ reste très orienté C++. PyQt, est très facile à utiliser, très prédictible mais on sent l'héritage d'un langage à classes rigides.

J'aime bien. Surtout qu'il y a une page dédiée au packaging, tâche ô combien essentielle et ingrate.

Le site web fait très pro, et dans l'esprit, ça me fait penser à django: utiliser vraiment la puissance de Python et pas juste un ou deux wrappers sur une lib existante.

Bon, sinon, c'est de la prog évenementielle classique (pour gérer du multi-touch, je pense qu'on y échappe pas) mais j'imagine que python permet de faire ça avec un peu plus d'élégance que feu Visual Basic ou Access.

Tu peux préciser la portabilité de Gambit Scheme ? Windows, MacOs, Android, iOs ? Des exemples d'applications graphiques qui l'utilisent ?

Pour Skype, même si le résultat n'est pas là, on parle bien de la contrainte que j'ai évoqué: un logiciel qui doit marcher chez tout le monde avec le minimum de développement spécifique.

Pour moi, le thème natif n'est pas fondamental.

D'une part, il existe des toolkits qui adaptent leur UI à la plate-forme (euh, j'ai parlé de Qt ?), d'autre part, même si le look n'est pas natif et que cela constitue une gène pour l'utilisateur, je trouve que c'est préférable à ne pas avoir de logiciel du tout sur cette plate-forme. Bon, c'est sur que un look Windows 3.0 dans un MacOs ou un Windows moderne, ça choque réellement. Mais si le soft est bien fait, l'utilisateur s'adaptera. Pleins de logiciels à succès ont des looks non natifs (iTune sous Windows, WinAmp, …)

Par contre, il est vrai que probablement un soft doit avoir deux versions. Une pour mobile et une pour desktop, car les interactions avec l'utilisateur ne sont pas pilotées pareille.

Quant à la solution de redévelopper un thème par OS visé, on oublie: d'une part, je ne suis pas graphiste, d'autre part, c'est justement le boulot du toolkit de gérer cela.

Tu n'as pas répondu très précisément: EFL, ça marche sous quelles plate-formes ? C'est stable ? C'est du C si je me souviens bien ? Est-ce que c'est suffisamment complet en terme d'abstraction de la plate-forme ?

Linux est quand même un projet industriel. C'est normal que les chercheurs aient peu de participation car la recherche se mélange mal avec les contraintes d'un projet industriel opérationnel comme Linux.

Faire de la recherche, c'est expérimenter, faire des trucs qui marchent pas et voir ce que ça donne, etc etc. Tout ça va pas de paire avec un noyau hyper stable dans toute les conditions possibles.

Tiens, j'en profite pour une autre question. Sur les desktop, quand on fait une appli, on fait en général des menus, des boutons, et checkbox, des listes, etc. Pour tout ça, on a des Widgets qui arrivent tout prêt à l'usage.

Comment ça se passe sur mobile ? J'ai cru comprendre qu'il faut faire soi-même ses boutons et tout parce que c'est à la mode. Pour un développeur comme moi qui est une b*te en graphisme, c'est l'horreur en fait…

On parle pas de la même chose.

Tu te places du point de vue de l'administrateur système qui se pose la question de déployer un programme sur ses postes. Programme qui apparemment répondrait déjà à pas mal de critère de déploiement automatisé.

Il me semble que l'auteur initial pose un problème différent, à savoir, du point de vue développeur, quelle est la bonne approche pour distribuer son programme face à la diversité des plate-formes. Le but étant de garder un programme simple à déployer et simple à mettre à jour pour les utilisateurs.

Donc je maintiens ma réponse, sous Windows, il est assez facile pour le développeur de générer un installeur, qui aura des propriétés d'installation automatisée (entre autres) et qui supportera un panel très large de versions de Windows.

Sous Linux, le problème est plus complexe. Tu as la solution de fainéant de fournir un .tgz avec un configure (ou un make install ou encore un python setup.py install)mais c'est loin d'être user-friendly.

Ensuite, solution 2, tu fournis un package. Le vrai truc de distrib. Sauf que qui dit package dit :
- choix dans le format: rpm ou deb ? Et ArchLinux ils vont se brosser ? Et gentoo ?
- choix dans la version de la distribution: pour une distribution donnée, il y a en général plusieurs versions utilisées par les utilisateurs à un moment donné. Laquelle choisir ?

Donc pour la problématique "comment faire un programme qui est facile à installer sur toutes les versions des OS que je vise" se résoud avec un installeur (et un peu d'huile de coude) sous Windows, et se résoud avec une armée entière de packageur sous Linux. Armée que peu de gens possèdent.

Et encore, je parle pas des bugs "sous Mageia 8.3.7 , ton soft plante en plein milieu d'un truc" qui te demandent donc d'avoir une Mageia 8.3.7 pour tester tout ça. Ouch…

Pour déployer massivement une application Qt sous Linux c'est facile. On publie un paquet sur un dépôt perso, et roulez. Mais quelqu'un a des retour d'expérience de déploiement massif d'application sur des postes Windows ?

Euh, je suis surpris que Zenitram n'aie pas déjà sauté sur l'occasion mais je vais le faire à sa place.

A ma connaissance, c'est exactement l'inverse: déployer une application sur Windows est facile, il suffit de faire un installeur et il y a pas mal d'outil pour en faire des biens. Il est aussi assez facile d'embarquer toutes les libs dont tu as besoin.

Sous linux au contraire, tu te trouves confronté à plein de questions à la con:
- quel format d'empaquetage utilisé ?
- comment m'assurer que toutes les libs dont j'ai besoin sont présentes dans la version où j'en ai besoin, pour le 86 distribitions Linux et 23 versions de chacune de ces distributions
- pour sauvegarder les données de l'utilisateur, il faut bidouiller pour créer un répertoire dans le HOME de l'utilisateur mais tu es obligé de développer vachement de code "à la con" pour gérer plein de cas particuliers.

Au final, tu passes en temps monstrueux en support pour quelques barbus.

Et maintenant, quid de Mac OS ? Je me pose la même question, facilité de déploiement…

Tu as raison dans le fait qu'ils n'ont pas à se justifier, mais je trouve ce choix d'une part moins lisible par les utilisateurs que le choix classique, et en contradiction avec la politique de Gnome qui vise à présenter quelque chose de simple aux utilisateurs.

Pour le grand public, je ne partage pas ton avis. Beaucoup de gens cherchent "à y comprendre quelque chose" et ce type de nommage de version n'aide pas. Et beaucoup de projets comme Gnome se préoccupent de la façon dont une nouvelle version est perçue et communiquée au grand public.

Après, c'est sur que ça empêche personne de dormir, mais ça me titille à chaque fois que je le vois.

Quand on voit que même mplayer s'est tourné vaguement vers une numérotation classique…

Certes. Mais, très honnêtement, connais-tu la marque de tous les objets, produits et services que utilise ?

Quelle est la marque de le chaise sur laquelle tu es assis ? De ton clavier ? De la fourchette avec laquelle tu manges le midi ? De ton verre ? Du sac-poubelle de la poubelle de ta cuisine ? Du post-it que tu utilises pour laisser un message ?

Sans pour autant approuver la politique de Gnome, on peut s’interroger légitimement sur la nécessité de connaitre toutes les marques et leurs vertus respectives.

Oui, j'ai quelques arguments. Tout d'abord, un panorama des logiciels existants. Si tu regardes l'ensemble des logiciels libres comme propriétaires, tu vois que cette pratique de version paire vs impaire est extrêmement marginale. Sans condamner ce qui est exceptionnel, cela questionne sur la légitimité de la pratique.

Dans le cas de Linux, cette pratique a été introduite à une époque où l'outil de gestion de source des gens modernes était CVS (les gens plus conservateurs utilisaient encore RCS). A cette époque, Linus dumpait toutes les 2 ou 3 semaines un gros tar.gz du noyau que tous les barbus s'empressaient de tester. Il y avait une réelle nécessité de nommer ces dumps de développement et Linus a utilisé une pratique plutôt originale: les versions impaires. Quand le bazar finissait par marchoter, il le passait en version paire. Linus étant un dictateur, personne n'a eu grand chose à discuter quant à la pratique.

Déjà à l'époque, les projets qui utilisaient un gestionnaire de source moderne (CVS donc), n'avaient pas ce besoin puisqu'il suffisait de récupérer la version en cours de développement avec un CVS up et qu'on s'en sortait avec une date.

Linus a fini pour trouver un système de gestion de source qui lui convient et a pu gérer confortablement les différents niveaux de stabilité du noyau avec différents dépotoirs. Il a en toute logique fini par abandonner les versions paires et impaires puisque les raisons qui avaient présidé à leur utilisation n'étaient plus.

Le seul argument qu'on opposait à l'époque où Gnome a fait ce choix que je critique, c'est "si Linux le fait, c'est une bonne pratique, faisons le aussi". J'imagine que ces même supporters de l'époque militent maintenant pour un versionnage classique, comme Linux. Si ce n'était pas le cas, ils seraient en flagrant délit d'incohérence !

Gnome n'est pas le seul projet à s'être posé la question de sa numérotation de version. Je me souviens d'avoir vu ce débat sur kde-core-devel. Récemment sur python-dev, les développeurs ont réfléchi à un autre schéma de sortie et de numérotation de version. Gentoo et Ubuntu ont aussi proposé un nouveau système plutôt basé sur des dates. On voit que Linux et Samba ont abandonné le système des versions paire et impaires, donc il y a clairement eu des discussions sur le sujet. Il y a aussi debian avec ses noms à la con dont personne ne se rappelle parfaitement identifiables.

Dans toutes les discussions auxquelles j'ai assisté, la réflexion sur la numérotation des version est axée pratiquement sur un seul sujet: l'utilisateur.

Les questions qui vont autour:
- comment l'utilisateur va-t-il comprendre quelle version il utilise ?
- comment l'utilisateur distingue les caractéristiques d'une version par rapport à une autre ? Plus stable, plus récente, avec des fonctionnalités en plus, qui plante plus, quelle version signaler dans les rapports de bug, etc
- comment l'utilisateur sait que sa version est à jour ?
- comment communiquer à l'utilisateur un changement important (on casse tout, plus rien de ce qui marchait avant ne marche) ?

Le schéma le plus courant est:
- un numéro de version majeur pour distinguer une famille de version
- un numéro de version mineur pour distinguer une mise à jour avec des nouvelles fonctionnalités
- un sous numéro de version pour distinguer des correctifs sans nouvelle fonctionnalité.
- un vocable particulier pour désigner les versions en cours de développement: instable, preview, alpha, beta, release candidate, demo,

Ce schéma est très courant, donc l'utilisateur "classique" s'y retrouve assez facilement: Python 2.6 est plus récent que Python 2.7, KDE 3 est une évolution majeure de KDE 2, Windows 8 Consumer Preview n'est pas la version finale mais une version en cours de développement, à tester par les utilisateurs et développeurs aventureux. Et Gnome 2.4.3, c'est comme Gnome 2.4.0 mais en plus stable.

Le choix de numérotation des versions instables en impaires embrouille un peu le message vers l'utilisateur. Raisonnablement, un utilisateur qui a un Gnome 2.4 et qui veut passer à la version suivante de Gnome s'attend à passer à la version 2.5 . Il faut alors lui explique que "oui mais non, parce que tu comprends, Gnome la version 2.5, c'est que pour les développeurs et les testeurs, donc c'est directement 2.6". Sans en faire tout un fromage, ça complique quand même le message vis à vis de l'utilisateur. Autre scenario, l'utilisateur vient de passer de Gnome 2.4 à Gnome 2.6 grâce à sa distrib et se dit ben zut, moi qui aime bien avoir la dernière version stable de mes logiciels, j'ai raté Gnome 2.5 .

Alors, pourquoi compliquer le message vis à vis de l'utilisateur ? En particulier pour un logiciel qui se veut accessible au plus grand nombre et pas juste aux barbus ?

De mon point de vue, il n'y a pas de bonne justification. Certes, c'est vaguement plus pratique pour les développeurs et les testeurs, mais ce public est justement capable de s’accommoder d'à peu près n'importe quel schéma de numérotation vu qu'ils sont impliqués dans le projet. Et les outils de gestion de conf modernes (déja avec subversion, encore plus avec git) permettent de gérer cette problématique extrêmement simplement.

Je trouve ça étrange pour Gnome de payer le prix d'une certaine incompréhension des utilisateurs pour un gain que je peine à voir.

Je comprends ce que vous dites, vous parlez des pratiques qui président au choix de la roadmap. Tout projet un tant soit peu évoluée en a (KDE, Python, Linux, etc), avec des numérotations qui fonctionnent très bien: un planning, des dates, des fonctionnalités ciblées, des numérotations de version qui permettent de distinguer ce qui est instable de ce qui est stable. Sur ce point-là, Gnome est comme tous les projets bien gérés.

Par contre, j'ai toujours pas vu un argument solide pour justifier l'absence de version impaire stable vis à vis du grand public.

Bon, j'espère que les développeurs de ton projet ne feront pas l'erreur de sortir encore une version instable dans deux ans. Sinon, on est mal barré…

Je vois pas très bien d'où tu tires l'information que ça marchait pas du tout pour Linux et très bien pour Gnome. Ce dont je suis sûr, c'est que les release impaires de Linux sont bien plus testées en terme de nombre d'utilisateurs que celles de Gnome (sans méchanceté, mais juste parce que Linux a une base d'utilisateurs supérieure).

Quant à ton serpent qui se mord la queue, tous les projets logiciels ont ce problème, que la version en cours de test soit appelée alpha, beta, 2.5, unstable, preview release ou autre, elle est toujours insuffisamment testée du goûts de développeurs. Je ne vois pas en quoi Gnome s'en sort mieux que n'importe quel autre projet sur ce plan.

Chez GNOME, ça ne change rien : on sait que ça sort tous les 6 mois.

Euh, donc tu penses que faire des release "time-based" est une justification pour utiliser la numérotation actuelle de Gnome. Tu peux détailler tes arguments ?

De nouvelles releases mineures sont faites après la sortie officielle pour corriger les plus gros bugs passés à travers des mailles du filet lors de la validation de la version de développement.

Oui, comme pour à peu près 95% des projets logiciels.

Du coup les versions x.y avec y impair servent juste de convention pour les alpha/beta/rc de la version x.(y+1),

Donc ça, je pense que j'avais compris.

et ont l'avantage de permettre une comparaison numérique (pas de alpha/beta/rc dans le nom de la version)

Bon, c'est un bon argument, mais orienté vraiment très très développeur. Et des projets qui utilisent le vocable alpha / beta / rc / preview arrivent quand même à faire des numérotations de versions qui se comparent numériquement.

On peut donc indiquer que telle fonction est obsolète depuis GTK 3.3.90, ce qui est plus précis pendant le cycle de développement que de dire que c'est obsolète depuis GTK 3.4.0.

Euh, tu veux dire que 3.4.0 , c'est moins précis que 3.3.90 ? De quel point de vue ?

Bon, c'est une petite pique cette histoire de version. Mais autant je comprends que des vieux projets comme apache ou samba utilisent encore cette façon de faire (ah tiens non, samba a arrêté depuis longtemps il semblerait), autant pour un projet qui se veut aussi moderne et dans le vent que Gnome, je trouve ça ridicule.

Le vraie problème, c'est que faire un desktop normal comme c'était le but de KDE ou Gnome il y a 10 ans, c'est devenu ennuyeux. Ce qui est fun maintenant, c'est les tablettes. Et les développeurs ont l'air d'aimer le fun, ou aimer croire qu'ils vont faire des trucs funs.

Donc les projets ont été convertis de force au monde des tablette alors que fondamentalement, c'était des desktop.

Moralité : vive XFCE.

J'ai volontairement utiliser les deux verbes, d'une part simplifier et d'autre part abêtir car je fais tout à fait la distinction. Je suis un grand fan de la simplification et de ce qui marche tout seul. Et de l'ergonomie intelligente.

Mais je suis contre « l'abetisation ». De mon point de vue, Gnome fait les deux en même temps.

Un truc qui me chiffonne sous Gnome, c'est d'avoir adopté une pratique de numérotation de version qui au moment où ils l'ont adopté, était déjà obsolète. Maintenant que même Linux a renoncé à ce système, que reste-t-il comme argument pour le défendre ?

Vis à vis d'un bureau qui se veut accessible au quidam novice en informatique, comment vous lui expliquez que il rate à chaque fois des mises à jour puisqu'il saute des versions ?

D'ailleurs à part Gnome, qui utilise encore des versions paires et impaires, surtout dans l'ère des gestion de sources décentralisés ?

Alors, il faut quand même pas exagérer: quand on utilise le vocable "ultra-expérimental", "essayer", "tatonner", "semblent", on est vraiment très très loin du domaine scientifique où une loi est établie et on peut s'appuyer dessus.

On est dans l'expérimentation, le brouillard, les annonces de campagnes politiques, les essais. La science commence en effet par ne rien savoir et découvre. Mais on est tout autant dans l'art et de l'artisanat que dans la science dans ce cas précis.

Donc dire "c'est une science, ferme ta gueule si t'es pas d'accord avec les choix qui sont faits", c'est vraiment du n'importe quoi.

Surtout que l'ergonomie est quelque chose de très subtile. Il y a des paramètres psychologiques, des paramètres sociétaux, liés aux habitudes, qui varient dans le temps.

Les utilisateurs qui ne connaissent que Windows trouvent le Mac pas ergonomique du tout. Tu peux aussi fabriquer des nouvelles habitudes d'ergonomie. Le coup du redimensionnement de la photo sur un téléphone est par exemple peu intuitif à la base (= tu peux pas savoir si tu ne l'as jamais fait ou vu faire) mais très ergonomique à l'usager. Alors que le réglage du son sur un Ipod est ergonomique et intuitif.

Bref, ce qu'il faut retenir (et je rejoins patrick_g à 100%), c'est que l'ère des bureaux qui proposent une interface générale en acceptant tous les composants extérieurs est révolue. Le but de Gnome, (tout comme Ubuntu et peut-être aussi pour le Spark de KDE, à voire …), c'est de proposer une interface controlée uniquement par Gnome et les autres éléments extérieurs sont priés de se ranger dans la catégorie "truc mal foutu que l'utilisateur utilisera que si il fouille son grenier et qu'on lui met le couteau sur la gorge".

C'est sur que c'est un choix qui se défend d’abêtir et de simplifier les interfaces pour l'utilisateur. Mais je trouve ça triste que ce soit maintenant le futur des bureaux Linux, plutôt que la recherche de la qualité, ce la compatibilité et l'acceptation de la diversité qui était auparavant leur roadmap.

C'est au contraire un système que se prête très bien aux tests unitaires et aux tests fonctionnels.

Donc la réponse à la question est non, il n'y a pas de tests unitaires bien que ce serait très facile à tester.