Petit historique de Gnome
Lors d'un “débat” (plutôt une série de mauvaises compréhensions), j'ai pu dire que Gnome et les extensions ça n'a jamais été une lune de miel, voir même que certains développeurs avaient pensé à supprimer cette possibilité.
Précisions utiles : Je suis un utilisateur de distributions Linux depuis 2003-2004. Au départ avec Slackware, puis Kubuntu, Xubuntu et Ubuntu. Aujourd'hui, après un passage par ElementaryOS, je suis sous PopOS. Mon expérience avec Gnome est celle d'un utilisateur qui a connu Gnome 2, puis le lancement (plutôt calamiteux) de Gnome 3 et les différents projets qui ont suivi (Mate, Cinnamon).
Aux origines de Gnome 3
En 2008, Gnome 3 est dans toutes les têtes des développeurs. Le nouveau DE (Environnement de Bureau) doit succéder à Gnome 2, implanté dans beaucoup de distributions Linux (Ubuntu étant l'une des plus populaires). Ce DE, plutôt léger même à son époque, satisfaisait beaucoup de besoins des utilisateurs.
Le blog de Owen Taylor parle bien de cette époque notamment avec son article “Implementing the next GNOME shell”.
Fin 2008, lors du GUIHackfest de Boston, Vincent Untz dévoile un concept d'interface :
Dans son article, nous pouvons voir plusieurs discussions menées et quelques décisions sur le développement de Gnome 3 :
- Le “menu” Activités permet d'avoir un seul endroit pour les applications en cours et celles à lancer. L'idée est de fusionner la vue avec le raccourcis “ALT-TAB” et le menu “Applications”, et tous les panneaux d'informations.
- Javascript, un langage populaire pour permettre l'engagement de la communauté dans le développement de Gnome. Javascript permet aussi de modifier le Shell. C'est la vision des “applets”, la même que celle de Gnome 2 ou de XFCE.
- Clutter, pour gérer la gestion des fenêtres et remplacer GTK+. À cette époque, Clutter est en phase de développement intense et utilise le GPU (OpenGL).
- Metacity, le gestionnaire de fenêtres de Gnome 2, est un héritage important pour l'équipe.
Déjà, si nous regardons les commentaires de l'article d'Owen, on peut voir que le choix de Javascript n'est pas le plus populaire, Python commence à être très utilisé parmi les communautés de développeurs. Il y a aussi des craintes concernant l'utilisation du GPU dans le rendu de Clutter.
Il faut dire que nous sommes en pleine période “Compiz”. Le rendu GPU est devenu populaire grâce à ces effets qui impressionnent et donnent à voir la puissance des distributions Linux.
Les extensions, une déception conceptuelle pour les développeurs, une popularité importante
Jiri Eischmann, dans son article “Story of Gnome Shell Extensions” parle de cet historique.
Dès le lancement de Gnome 3, le choix des extensions en Javascript se révèle payant. De nombreux développeurs s'impliquent pour apporter des extensions au bureau de Gnome. Mais les choix de design de l'équipe (plutôt radicaux) sont mis à mal par ces extensions. De plus, les développeurs d'extensions ne s'impliquent pas dans le développement de Gnome, mais restent sur leurs projets sans s'impliquer davantage.
L'équipe décide de leur donner plus de visibilité en apportant Gnome Extensions pour rationaliser tout cela avec des connecteurs dans les navigateurs Firefox et Chrome. Cette application est séparée du reste des paramètres de Gnome. Le développeur Tobias Bernard pense même que cette application doit rester comme telle, car c'est juste un hack :
“If you make extension installation/management nicer that makes them seem like even more of a supported feature, rather than the hack it is...”
En 2012, Gnome 3 devient de plus en plus instable à cause de certaines extensions. En 2016, avec l'introduction de Wayland, l'équipe a pu penser que cela allait être mieux (séparations des processus), mais la conception même de Gnome (Mutter / Shell dans un même processus) faisait que si un des composants plantait, les deux plantaient.
L'article date de 2018 et Jiri Eischmann fait le constat amère que les extensions apportent plus de problèmes d'instabilités qu'autre chose au projet :
“desktop crashes caused by GS extensions are by far the most frequent problem I’ve seen recently”.
C'est bien à cette époque que certains développeurs posent la question du support des extensions dans Gnome. À chaque version de Gnome (3.36, 3.38...) beaucoup d'extensions deviennent incompatibles.
Entre désactivation après survenue d'un bug (avec la fermeture de la session utilisateur), rendre incompatibles la plupart des extensions en mettant en place une API ou une autre solution de séparation entre Mutter et Shell (une solution complexe en ces temps de cohabitation entre X11 et Wayland) la décision, à l'époque, n'est pas de faire de choix radical.
JohnMacHugh sur le wiki de Gnome en parle aussi en ces termes.
Il faut bien comprendre ici que le débat à propos des extensions n'est pas le même que celui des thèmes. Il s'agit d'un enjeu entre un langage populaire (Javascript) aux débuts de Gnome 3 qui rend les choix de l'équipe incohérents et instables et une popularité, bienvenue, héritée des “applet” de Gnome 2 / XFCE.
L'équipe de Gnome n'apprécie pas que ses décisions de design ne soient pas respectées. On le voit lorsqu'il est question de “theming” avec le site “StopThemingMyApp”
Une intégration en cours de rationalisation
Comme dit plus haut, l'application qui gère les extensions dans Gnome est en dehors des paramètres du bureau de Gnome. Certaines distributions (PopOS) ont décidé d'inclure ces paramètres dans les paramètres globaux au mépris des choix de la communauté de Gnome. Quelques tensions plus tard et quelques débats sur le theming font que PopOS décide de ne plus continuer avec Gnome pour ses prochaines versions : ils développent leur propre DE, Cosmic, codé en langage RUST.
Canonical ayant abandonné son interface Unity dans Ubuntu. Sa distribution phare utilise Gnome (comme à l'ancien temps de Gnome 2). Il est important de voir ici que Ubuntu utilise des extensions “maison” directement implantées (app indicator par exemple). C'est aussi un point de débat dans la communauté de développeurs de Gnome.
Tobias Bernard en parle dans son article “Community Power Part 4: The GNOME Way” :
“Every preference has a cost, and this cost rises exponentially as you add more of them. This is why we avoid preferences as much as possible, and focus on fixing the underlying problems instead.”
Et la partie concernant les extensions illustre bien le propos :
“Shell extensions are always going to be a niche thing. If you want to have real impact your time is better invested working on apps or GNOME Shell itself.”
Si vous voulez vous investir efficacement dans Gnome, votre temps sera mieux dépensé si vous développez des applications plutôt que des extensions.
Conclusion
L'équipe de Gnome a certainement besoin de clarifier ses positions concernant ce sujet. Autant les choix de design sont des choix à mettre en débat, mais ils s'imposent à tout utilisateur de Gnome. Les extensions, quant à elles, montrent une dynamique d'un développement communautaire. À l'instar de sites comme gnome-look, les choix de l'équipe de Gnome sont mis à mal par les thèmes, les extensions instables... Et ce, même si Allan Day a pu mettre en avant “The Gnome Way”, aujourd'hui, 6 ans après et avec le développement intense des différentes versions de Gnome, la question des extensions demeure et de ses incompatibilités avec.