Journal GNOME Stop Me Now

Sommaire

• • Sister Disclaimer
  • When I amd 64
  • The Dark Sidebar Of The Moon
  • You Can't Always GET What You Want
    • 423 Locked
    • 100 Continue
    • 406 Not Acceptable
    • 418 I'm a teapot
  • Forkgiven
  • APTite For Construction
  • Y'en a un peu plus, je vous le mets quand même ?
    • Je Theme Moi Non Plus
    • I Believe I Can Fail
    • After Hours
  • The End

Cher 'Nal,

J'écris ce journal pour clore un chapitre qui m'a bien frustré depuis 2 ans, mais que j'ai pu résoudre grâce à tout ce qu'offrent les logiciels libres.

Sister Disclaimer

• TL; DR : HowTo.Fix[(Nautilus >= 43).ui == feeling(crap)]

Même s'il concerne un problème avec GNOME, le but n'est donc pas de se moquer de lui, ça ne serait pas politiquement correct.

Je fais surtout un retour d'expérience, en tant qu'utilisateur avancé : il y aura donc surtout du texte (avec un effort notable mais peut-être un peu lourd sur les titres), avec néanmoins sur la fin un peu de css, xml, et même 3 lignes de c !

When I amd 64

J'ai quitté Windows pour Linux à l'été 2010, suite à de premières expériences positives de « hacking », via Litestep, pour ceux qui connaissent.

C'était la grande époque d'Ubuntu, mais après l'avoir testé, et aussi Kubuntu, mon choix s'est fixé sur un GNOME plus «upstream» : je me suis installé sous Fedora.

Ce qui m'avait grandement décidé, c'était la réflexion sur le concept de bureau, avec en particulier le mode spatial de Nautilus. Je m'étais fait une personnalisation aux petits oignons des différents dossiers dont j'avais besoin.

Et moins d'un an plus tard, GNOME passe à la version 3 :

• C'est la fin pour le mode spatial de Nautilus. Je dois jeter à la poubelle tous mes efforts, mais je conserve une navigation épurée, avec seulement une vue du dossier en cours occupant toute la fenêtre. Je n'utilise que rarement le panneau des raccourcis (F9), tous mes dossiers usuels ayant des raccourcis sur le bureau.

• C'est pas grave, je suis encore un jeune fou, ouvert à la disruption : j'embrasse avec enthousiasme l'overview du GNOME Shell (Document d'intention), qui permet une gestion originale et très efficace du bureau, que ce soit à la souris (combien de fois ensuite n'aie-je déplacé ma souris dans le coin supérieur gauche de l'écran sous Windows au boulot, sans aucun effet…), ou au clavier :

  • le symbole de la touche 🪟 (Windows) devient signifiant : son appui affiche toutes les fenêtres ouvertes, et amène une certaine logique mnémotechnique :
    • 🪟 + 🠠, 🠡, 🠢 ou 🠣 déplace la fenêtre active,
    • 🪟 +⇞ ou ⇟ change de bureau
  • beaucoup de tâches de gestion du bureau deviennent accessibles avec un seul doigt :
    • 🪟,é,t,e,i,n,d,r,e permet d'éteindre élégamment l'ordinateur avec un bébé dans les bras, par exemple.

• L'apparition des headerbars me fait craindre le pire, mais la conversion réussie de Gedit me remplit de joie : cette minimisation du chrome des applications au bénéfice de leur contenu amène une certaine rationalisation chez moi : Nautilus et Gedit s'ouvre par défaut à la même taille que mon terminal (Tilix : 722×456 px). Cela me permet d'avoir jusqu'à 4 fenêtres de ces applications ouvertes en même temps, en maintenant mes raccourcis de bureau accessibles, ou bien 2 fenêtres ouvertes à côté d'une application plus complexe (LibreOffice en général) sur une moitié d'écran.

Bref, je me créé un workflow personnel, qui peu à peu diverge de la vision GNOME : le cycle de publication bisannuel de Fedora provoque donc des changements qui nécessitent certaines adaptations (évolution des notifications) ou contournements (suppression des icônes sur le bureau) plus ou moins poussés.

La forte poussée anti-theming de la fin des 2010's m'a aussi particulièrement fatigué : je trouve ça bien que chacun puisse décorer son "home" à sa guise (icônes, chrome & pas seulement une couleur d'accentuation) : l'uniformisation transforme à mon sens l'ordinateur personnel en standard industriel déprimant.

Bref la sortie de GNOME 40 en mars 2021 est la goutte de trop : la réorganisation horizontale des bureaux virtuels dans l'overview fait perdre la cohérence des raccourcis clavier, diminue la place de la "zone utile" et m'évoque des plateaux de cantine à remplir d'apps , et elle ne me semble être là qu'avant tout pour avoir un changement visuel marquant pour le gros saut de numérotation.

Je pourrais attendre qu'une extension corrige l'overview (ce qui arrivera vite), mais je décide que j'ai passé l'âge des mises à jour nécessitant de revoir mes habitudes (sous prétexte d'amélioration) tous les 6 mois : je cherche une nouvelle distribution, ayant une durée de maintenance longue, afin de ne plus me poser ces questions que le moins souvent possible : je choisis Debian, et prend conscience que je suis devenu un vieux con.

Mais ce calme au niveau desktop me permet d'improver mon efficiency de 42% (estimation La RACHE).

Pour résumer cette partie concernant mon rapport à l'IHM chez GNOME, même si l'innovation peut amener des progrès spectaculaires, des changements trop fréquents risquent de devenir contre-productifs.

The Dark Sidebar Of The Moon

Mars 2023 , Debian annonce le Hard Freeze de sa nouvelle version. Il est temps pour moi de voir ce que GNOME est devenu (version 43, désormais), et quelles adaptations, ou contournements il me faudra fournir. Je l'installe dans une VM, et là, c'est le drame.

Le panneau latéral de Nautilus n'est plus masquable : la zone de contenu passe de 90% à 60 % de la fenêtre, et en conséquence au lieu de voir jusqu'à (6×4=) 24 fichiers simultanément, je ne peut plus en voir que (3×3=) 9 !

Une rapide recherche Internet me permet de découvrir que je ne suis pas le seul à qui ça pose problème.
Après malheureusement, ce n'est pas un bug, mais une fonctionnalité : Selon les développeurs, cacher le panneau latéral n'était qu'un pis-aller pour utiliser Nautilus à de petites tailles, mais comme dorénavant Nautilus fait ça automatiquement quand on le redimensionne, ce n'est plus nécessaire (lien).

• Bon j'ai un peu l'impression qu'on réécrit l'histoire ici : montrer/cacher le volet latéral était possible depuis la première version de Nautilus inclue dans GNOME (en 2001) , et je doute très fort que c'était la raison d'alors (d'autant plus si on regarde les autres gestionnaires de fichiers, qui quasiment tous le permettent toujours).

• J'ai plutôt la sensation que l'on sacrifie ici l'usage pour l'apparence : ainsi, Nautilus ressemble plus à d'autres applications de base de GNOME, comme Settings, Disks, Contacts, Characters ou Calendar.

You Can't Always GET What You Want

Bon voyons d'abord s'il y a moyen de s'adapter : En agrandissant un peu la fenêtre, je peux monter jusqu'à 16 fichiers affichés, mais ça m'est insuffisant, et il me faut faire abstraction de l'espace gaspillé par la barre latérale

N'ayant pas de capacités particulières en programmation, il semble donc nécessaire de demander aux développeurs de Nautilus d'améliorer la situation.

423 Locked

Cela fait longtemps que les équipes de GNOME sont réputées pour être teutillonnes sur les demandes d'améliorations qu'on leur soumet, et les pages que j'ai consulté jusqu'ici me suggèrent que ce sujet aussi est délicat : il me faut trouver une bonne formulation du problème : il me semble qu'il faut partir d'un exemple concret (use case), et éviter le terme bug.

Ça tombe bien, il existe un autre template de ticket sur le gitlab de Nautilus : Shortcoming.

J'en profite pour élargir le problème à la vue en liste, qui juste avant le seuil de disparition automatique de la barre latérale est bien inutilisable (et c'est la version en cours dans Debian Bookworm) :

Et voilà : https://gitlab.gnome.org/GNOME/nautilus/-/issues/2953 ça passe.

Bon je ne me fais pas directement jeter, mais après 4 commentaires en 5 jours, ça ne bouge plus vraiment pendant 1 mois.

Apparemment, les devs bossaient sur un changement de "widgets" pour le comportement adaptatif de Nautilus. une fois celui-ci integré, j'ai juste un message d'un dev qui me dit que comme ce patch a un effet sur le problème reporté, sa description est de facto obsolète, et clos donc le ticket, sans vérifier que c'est bien le cas.

Ce patch a pour conséquence que la taille du volet latéral change selon la largeur de la fenêtre, mais ça ne m'affiche toujours que 4 icônes de large…

100 Continue

Un peu piqué par cette clôture abrupte du ticket, j'en rouvre un dans la foulée, en copiant collant le contenu du précédent : https://gitlab.gnome.org/GNOME/nautilus/-/issues/3001

• J'ajoute juste en premier commentaire des captures d'écran pour montrer comment la situation n'a pas vraiment évolué.

• Évidemment un des premiers commentaires pointe le fait qu'il faut que je mette aussi à jour mes captures d'écran dans la description du ticket

La discussion va néanmoins plus vite, et il y a une recherche de solution autour de la taille limite à partir de laquelle se cache automatiquement la barre latérale : même si ce n'est pas mon souhait initial, je participe volontiers à la résolution proposée : on me propose un seuil de déclenchement à 768 sp (screen pixels : pour tenir compte des écrans HiDPI). Ce qui me convient enfin.

Néanmoins, comme l'un des devs le souligne, ce seuil est peut poser des problèmes : je plussoie fortement qu'il faudrait consulter plus largement.

Il y a alors un long silence (c'est l'été), et un commit vient clore le ticket sans aucun message fin août, avec un seuil fixé finalement à 682 sp. (sur quels critères ? Mystère)

Bref la situation a un peu progressé : je peux voir jusqu'à (5×3) =15 icônes, en réduisant (!) la taille (habituelle) de ma fenêtre . Et je suppose que c'est mieux aussi pour les utilisateurs de la vue en liste.

Mais j'essaie d'argumenter que c'est bancal que pour une largeur de fenêtre comprise entre 682 et ± 850 sp, Nautilus a une plus petite zone de contenu qu'en dessous de 682 sp.

Vainement.

Néanmoins sur ce ticket, même s'il m'a été difficile de ne pas pointer les failles de raisonnement qui bloquent la recherche de solutions, la conversation a été instructive : elle m'a permis par exemple de découvrir l'usage de GNOME Builder, l'IDE dédié, qui permet très simplement de récupérer les sources de Nautilus, de les modifier (ici en l'occurence, il ne s'agissait que de modifier la valeur du seuil de taille basculant le fonctionnement de Nautilus), de compiler et exécuter un test, voire de générer un flatpak pour installation à la suite.

406 Not Acceptable

Néanmoins, un dev m'informe qu'une discussion a eu lieu à ce sujet sur le chat matrix, mais que proposer un bouton pour basculer la vue du volet latéral risquerait d'ouvrir la boîte de Pandore (sur des problèmes de design et d'ergonomie, et une surcharge de maintenance)

Voulant être constructif, je ne relève pas que c'est la situation existante aux plus petites tailles (cf GIF plus haut), mais me propose pour réfléchir à cette boîte de Pandore.

Je m'inscris donc à la chatroom matrix de Nautilus pour en consulter l'historique, afin de retrouver la conversation évoquée par le dev, mais c'est impossible : je n'ai accès à l'historique que jusqu'au moment de mon inscription.

Je demande alors si une bonne âme peut me transférer cette discussion, mais malgré la bonne volonté, la seule chose trouvée ne correspond pas.

Bien que dans le noir, et voulant clore proprement le chapitre, je crée un ticket feature, avec quelques propositions initiales, pour amorcer la discussion.

https://gitlab.gnome.org/GNOME/nautilus/-/issues/3251

Le ticket est directement fermé, car les devs préfèrent que les "nouvelles" fonctionnalités soient discutées sur leurs forums discourse.

J'apprends néanmoins que certains devs de nautilus aimeraient bien que cette opportunité revienne, mais que les designers les ont convaincus que c'était une mauvaise idée.

J'ai donc créé une entrée de forum : https://discourse.gnome.org/t/ability-to-hide-the-sidebar-at-every-size/18850/1 .

Je n'ai quasiment qu'une contribution du dev qui a principalement interagi avec moi, ne me parlant que des problèmes de la proposition bouton, sans aucune intervention des designers.

Je ne rappelle pas que dans mon entrée, j'ai bien précisé que cette proposition ne fait que reprendre le comportement de nautilus aux petites tailles, mais ça me permet de clore proprement ce chapitre de "bug reporting", en me disant que j'étais allé au bout de ce que je pouvais faire.

418 I'm a teapot

Il me faut donc envisager un changement de gestionnaire de fichiers, alors je réalise un comparatif (en rouge sont indiqués les gestionnaires qui ne permettent pas de cacher le volet latéral):

Nautilus 3.38 était effectivement le meilleur gestionnaire de fichier pour afficher le contenu d'un dossier pour mon usage, Nautilus 43.2 le pire, mes rapports de bugs ont un peu contribué à améliorer la situation, mais donc hormis rester sous Nautilus 3.38, je ne peux que perdre en usage : je décide donc de rester sous Debian Bullseye autant que possible : il y a toujours possibilité qu'une nouvelle version de Nautilus change la donne (spoiler : ça n'arrivera pas).

Bref pour moi, le bilan de cette phase est que la remontée de bogues est plus compliquée chez GNOME, à priori à cause de la "vision" de designers qui priorisent l'uniformisation au-dessus de tout.

Dans la dernière version de Nautilus, on ne peut toujours pas cacher le volet latéral : le chrome de la fenêtre peut donc toujours prendre jusqu'à 40 % de la fenêtre, et il y a forcément 2 icônes pour la recherche…

Néanmoins, j'ai contribué quand même à améliorer la situation pour la vue en liste :

Forkgiven

Durant l'année 2024, je me lance donc occasionnellement dans le fork de l'apparence de Nautilus, ayant découvert avec mes rapports de bogues, comment utiliser GNOME Builder pour faire des tests rapidement, et le fait que toute la description de l'interface de Nautilus (au format XML) est bien organisée dans le répertoire src\resources\ui, et le fichier m'intéressant en particulier étant nautilus-window.ui.

• Remarque : L'utilisation de GNOME Builder me fait travailler sur les fichiers de la forge git de Nautilus. En conséquence, le comportement adaptatif de Nautilus utilise une version plus récente de LibAdwaita, qui n'utilise plus les mêmes méthodes que celles du Nautilus fourni avec Debian Bookworm. Ça ne me dérange pas plus que ça, l'objectif étant d'être prêt pour Trixie.

la technique la plus simple pour ne plus avoir le volet latéral en permanence consiste à modifier le seuil de déclenchement du mode adaptatif, en s'inspirant de ce qui avait été fait par les dev de Nautilus dans mon ticket (cf supra) :

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -200,7 +201,7 @@
     </child>
     <child>
       <object class="AdwBreakpoint">
-        <condition>max-width: 682sp</condition>
+        <condition>max-width: 750sp</condition>
         <setter object="split_view" property="collapsed">True</setter>
         <setter object="split_view" property="enable-show-gesture">True</setter>
         <setter object="split_view" property="enable-hide-gesture">True</setter>

Ça marche facilement, mais ça déplace en bas de fenêtre les boutons d'historique et de réglage de la vue.

Je préférerais une méthode qui me permette aussi de cacher le volet latéral aux plus grandes tailles. La lecture de la doc de LibAdwaita m'indique que le widget AdwOverlaySplitView qui gère le comportement adaptatif de Nautilus possède une propriété booléenne show-sidebar qui détermine si le volet latéral est visible ou non :

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -101,6 +56,7 @@
               <object class="AdwOverlaySplitView" id="split_view">
                 <property name="enable-show-gesture">False</property>
                 <property name="enable-hide-gesture">False</property>
+                <property name="show-sidebar">False</property>
                 <property name="max-sidebar-width">240</property>
                 <property name="sidebar-width-unit">px</property>
                 <property name="sidebar-width-fraction">0.2</property>

Et le volet latéral est maintenant masqué par défaut : on ne peut pas l'afficher, mais c'est déjà beaucoup mieux. Néanmoins, je constate avec surprise que ma taille de fenêtre habituelle ne m'affiche que 5 icônes par ligne au lieu de 6 :

Après m'être gratté un peu la tête, en utilisant l'excellent outil GTK Inspector, je constate que les fichiers sont dans objets appelés NautilusViewCell. Je réalise aussi qu'il y a un fichier style.css dans le dossier src\resources. Et effectivement en ajustant le padding de ces objets, je retrouve quasiment le confort que j'avais avec Nautilus 3.38 :

--- a/src/resources/style.css
+++ b/src/resources/style.css
@@ -149,7 +149,7 @@
   border-radius: 12px;
 }
 .nautilus-grid-view #NautilusViewCell {
-  padding: 6px;
+  padding: 0px;
   border-radius: 12px;
 }

Ne reste que le plus difficile, trouver comment réactiver le raccourci clavier (F9) pour afficher le volet latéral au besoin, même au delà du seuil d'adaptabilité, pusiqu'il est opérationnel en dessous.

Me rappelant qu'ils étaient souvent qualifiés d'accelerators, une recherche dans les fichiers sous GNOME Builder semble m'indiquer que ce raccourci est défini dans le fichier nautilus-window.c :

    nautilus_application_set_accelerator (app, "win.toggle-sidebar", "F9");

Gasp, c'est du C, un langage bien plus compliqué à décrypter pour moi que le XML ou le CSS. Heureusement, 10 lignes en dessous, je lis :

#undef ACCELS

    action = g_action_map_lookup_action (G_ACTION_MAP (window), "toggle-sidebar");
    g_object_bind_property (window->content_flap, "folded",
                            action, "enabled", G_BINDING_SYNC_CREATE);

Je supprime ces lignes, et ça marche. ÇA MARCHE !

Je peux alors obtenir un flatpak de Nautilus, mais pour l'intégrer plus proprement, il faut que je m'intéresse à l'empaquetage Debian :

APTite For Construction

Il me faut travailler sur la source du paquet Debian, récupérable avec la commande :

apt source nautilus

Que je peux recompiler en paquets .deb ensuite avec la commande :

debuild -b -uc -us

Malheureusement les tests exécutés durant la construction échouent chez moi :

10/20 nautilus:displayless / test-file-operations-trash-or-delete           FAIL             0.08s   killed by signal 5 SIGTRAP
 7/20 nautilus:displayless / test-file-operations-copy-files                FAIL             0.67s   killed by signal 5 SIGTRAP
 9/20 nautilus:displayless / test-file-operations-move-files                FAIL             1.53s   killed by signal 5 SIGTRAP

Avec un peu de recherche, je découvre que je peux sauter les tests, en utilisant une variable globale, avant d'exécuter la construction. La suite de commandes ci-dessous me permet de récupérer des fichiers deb opérationnels :

export DEB_BUILD_OPTIONS=nocheck
debuild -b -uc -us

Ne reste qu'à automatiser la modification des sources des paquets, pour ne pas avoir à modifier à la main chacun des fichiers à chaque mise à jour de Nautilus.

je cherche d'abord dans diverses docs d'empaquetage de Debian comment mettre en place des patchs. Je mets en place dquilt, que j'utilise ainsi :

#pour démarrer l'écriture d'un patch ()
dquilt new fix-nautilus-sidebar.patch

# pour indiquer les fichiers à surveiller :
dquilt add src/nautilus-window.c src/resources/style.css src/resources/ui/nautilus-window.ui

# pour récupérer les modifications des fichiers modifiés :
dquilt refresh

ça me permet de récupérer un fichier de patch que je peux utiliser avec la commande patch -p1 -i debian/patches/fix-nautilus-sidebar.patch.

Il y a encore une commande à utiliser pour incrémenter comme il faut le numéro de version du logiciel, afin que je puisse installer les paquets debian :

dch -n "Fix Nautilus Sidebar"

J'ai tout ce qu'il me faut pour automatiser le traitement : je récupére mon patch fix-nautilus-sidebar.patch :

From: hugotrip 
Description: allow to hide the sidebar & more
--- a/src/nautilus-window.c
+++ b/src/nautilus-window.c
@@ -1135,11 +1135,6 @@

     nautilus_window_on_undo_changed (nautilus_file_undo_manager_get (), window);

-#undef ACCELS
-
-    action = g_action_map_lookup_action (G_ACTION_MAP (window), "toggle-sidebar");
-    g_object_bind_property (window->split_view, "collapsed",
-                            action, "enabled", G_BINDING_SYNC_CREATE);
 }

 static gboolean
--- a/src/resources/style.css
+++ b/src/resources/style.css
@@ -149,7 +149,7 @@
   border-radius: 12px;
 }
 .nautilus-grid-view #NautilusViewCell {
-  padding: 6px;
+  padding: 0px;
   border-radius: 12px;
 }

--- a/src/resources/ui/nautilus-window.ui
+++ b/src/resources/ui/nautilus-window.ui
@@ -104,6 +104,7 @@
                 <property name="max-sidebar-width">240</property>
                 <property name="sidebar-width-unit">px</property>
                 <property name="sidebar-width-fraction">0.2</property>
+                <property name="show-sidebar">False</property>
                 <property name="sidebar">
                   <object class="AdwToolbarView">
                     <property name="reveal-bottom-bars"

Je crée un script bash fix-nautilus-sidebar.sh (qui nécessite quand même mon intervenion à 2 moments) :

#!/bin/bash

# récupération de la source des paquets Debian
apt source nautilus
#Application de mes modifications
cd nautilus-48.*
patch -p1 < ../fix-nautilus-sidebar.patch
# mise à jour du CHANGELOG, pour augmenter le numér de version :
dch -n "Fix Nautilus Sidebar"
# construction des paquets :
export DEB_BUILD_OPTIONS=nocheck
debuild -b -uc -us
# installation des paquets :
cd ..
rm *dbgsym*.deb & rm *dev*.deb
sudo apt install ./*.deb

et ensuite, sous ma VM de test Trixie, si une mise à jour modifie Nautilus, j'ai juste à copier ces 2 fichiers dans un dossier temporaire, y exécuter le script shell, pour récupérer ma version patchée de Nautilus.

Bref, pour résumer il est erroné de dire que GNOME n'est pas personnalisable, simplement, ce n'est (vraiment) pas à la portée de l'utilisateur de base.

Y'en a un peu plus, je vous le mets quand même ?

Je Theme Moi Non Plus

Est-ce que c'est possible d'avoir les headerbars des fenêtres colorés à son goût ? Mais bien sûr, ce n'est que du CSS à écrire dans le fichier ~/.config/gtk-4.0/gtk.css .

Par contre choisir le sélecteur headerbarne suffit pas à tout colorer le haut de la fenêtre, il faut choisir le sélecteur windowhandle, qui colorie aussi les barres d'outils qui apparaissent éventuellement en bas de la fenêtre (ce qui me permet d'apprendre que le cliquer-glisser sur cette zone permet aussi de déplacer une fenêtre), et le changement est ultra-simple :

windowhandle {
    background:#41495c; /* couleur d'arrière-plan */
    color:#e9ecf2; /* couleur de premier plan */
}

Pour la peine j'y ai aussi ajouté quelques légers points, pour mieux correspondre au thème gtk3 actuel de mes applications.

windowhandle {
    background:#41495c;
    color:#e9ecf2;
}

window{
    border-radius: 7px;
}

.sidebar-pane {
    background:#eaeef3;
}

windowcontrols > .close {
    background-image: radial-gradient(#bf616a, #bf616a 48%, transparent 48.5%);
}

I Believe I Can Fail

j'ai essayé de modifier le fichier src\resources\ui\nautilus-window.ui pour remettre le volet latéral sous la headerbar, mais j'ai atteint les limites de mes capacités, semble-t-il.

De même au niveau css, désaplatir les boutons semble nécéssiter pas mal de boulot, encore.

After Hours

En faisant mes recherches pour ce journal, j'ai pu constater que le problème du volet latéral entraînait aussi maintenant des frictions visibles au sein de l'équipe de GNOME.

• sur cette conversation de 2024, c'est un des membres de l'équipe GNOME qui met les pieds dans le plats.

• Mais le plus hallucinant, c'est qu'au mois de juin dernier, c'est un des dév de Nautilus qui a donné une méthode pour réafficher le volet latéral, suivant sensiblement la même méthode que moi : patch puis recompilation.

The End

Je devrais maintenant être tranquille pour au moins 2 versions de Debian : j'espère toutefois ne pas avoir à faire de journal en 2029, à ce sujet.

Merci néanmoins à TOUTE la communauté GNOME pour son travail fantastique dont je profite chaque jour : ce n'est pas mon désaccord sur certains points qui me ferait tout jeter tout aux orties.