URL: https://linuxfr.org/news/gnome-stop-me-now Title: GNOME Stop Me Now Authors: hugotrip BAud Date: 2025-08-06T18:16:09+02:00 License: CC By-SA Tags: Score: 3 Voici un retour d'expérience montrant les possibilités de « configuration » de GNOME lorsqu'un comportement -- pourtant apprécié par certains -- a été malencontreusement « retiré ». hugotrip réussit ce tour de force pour Nautilus dont le panneau latéral n'est plus masquable à partir de GNOME 43, ce qui fait perdre de la place à l'écran lorsque plusieurs fenêtres sont affichées. C'est l'occasion de découvrir les (non-)possibilités de configuration de GNOME et les moyens de réussir à y accéder néanmoins au travers d'une démarche constructive, didactique et factuelle mettant en lumière les relations particulières des développeurs et _designers UI/UX_ (interface et expérience utilisateur) de GNOME avec leur gestionnaire de demandes et de rapports de bugs. Vous y apprendrez : - la patience nécessaire à faire prendre en compte une demande et une bonne manière d'y arriver - comme quoi GNOME est effectivement configurable au prix de mettre les mains dans le cambouis, de passer par du `CSS` et un peu d'`XML`, voire de patcher un peu de code source `C` grâce à l'aide bienveillante de développeurs pour conserver la fonctionnalité de configuration disparue - que `CSS` et `XML` n'ont pas de raison de faire peur lorsqu'il s'agit de modifier une valeur (tout n'est pas à réécrire) et que finalement le code `C` lorsque c'est rétablir des lignes enlevées précédemment, cela ne demande « que » de retrouver la modification les ayant enlevées et pour cela savoir (un peu) se servir d'un gestionnaire de code source Bonne lecture de ce qui était un journal et qui lèvera un coin du voile sur les (im)possibilités de configuration de GNOME. Et pour les faire prendre en compte : de la patience, beaucoup de patience et encore de la patience, tout cela dans la joie et la bonne humeur _o/ ---- [Journal à l’origine de la dépêche](https://linuxfr.org/users/hugotrip/journaux/gnome-stop-me-now) [Nautilus navigateur de fichiers de GNOME](https://apps.gnome.org/fr/Nautilus/) [GNOME HIG : bonnes pratiques pour l'interaction humain-machine (IHM)](https://developer.gnome.org/hig/index.html) [GNOME Builder pour créer des applications](https://apps.gnome.org/fr/Builder/) ---- Cher 'Nal, J'ai écrit 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](https://fr.wikipedia.org/wiki/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](https://fr.wikipedia.org/wiki/GNOME_Fichiers#Interface_de_pr%C3%A9sentation_de_fichiers) 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](http://hugotrip.free.fr/dlfp/Nautilus/GNOME_Shell-20091114.pdf)), qui permet une gestion originale et très efficace du bureau, que ce soit à la souris (combien de fois ensuite ai-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 conservant 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 biannuel 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](https://linuxfr.org/forums/linux-general/posts/migration-fedora-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](https://gitlab.gnome.org/GNOME/nautilus/-/issues/2427) [ça](https://gitlab.gnome.org/GNOME/nautilus/-/issues/2725) [pose](https://gitlab.gnome.org/GNOME/nautilus/-/issues/2635) [problème](https://gitlab.gnome.org/GNOME/nautilus/-/issues/2430). Après malheureusement, [ce n'est pas un bug, mais une fonctionnalité](https://fr.wiktionary.org/wiki/it%E2%80%99s_not_a_bug,_it%E2%80%99s_a_feature) : 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](https://discourse.gnome.org/t/sidebar-on-nautilus-nightly-wont-hide-even-when-asked-nicely-43-rc-e11f9dd5d/10987/7)). ![animation montrant le masquage automatique de la barre latérale](http://hugotrip.free.fr/dlfp/Nautilus/Files-43-with-autohide-sidebar-2.gif) Source de l'image : [debugpoint.com](https://www.debugpoint.com/gnome-43/) - [CC-BY-SA](https://creativecommons.org/licenses/by-sa/4.0/) * 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 incluse 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](https://apps.gnome.org/en/DiskUtility/), [Disks](https://apps.gnome.org/en/DiskUtility/), [Contacts](https://apps.gnome.org/en/Contacts/), [Characters](https://apps.gnome.org/en/Characters/) ou [Calendar](https://apps.gnome.org/en/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](https://mail.gnome.org/archives/usability/2005-December/msg00022.html) sur les demandes d'améliorations qu'on leur soumet, et les pages que j'ai consultées 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) : ![Je voudrais le fichier ...](http://hugotrip.free.fr/dlfp/Nautilus/Liste43.2.png) 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 intégré, j'ai juste un message d'un dev qui me dit que comme ce patch a un effet sur le problème remonté, 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 fermeture 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 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](https://gitlab.gnome.org/GNOME/nautilus/-/commit/f19fe992444760f55b7aed308675745801603445) 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 animé 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](https://discourse.gnome.org/tag/nautilus). J'apprends néanmoins que certains devs de nautilus aimeraient bien que cette opportunité revienne, mais que les designers les ont convaincu 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) : ![Représentation graphique du nombre de fichiers affichés en fonction de la part de la fenêtre dédiée à l'affichage des fichiers pour quelques gestionnaires de fichiers](http://hugotrip.free.fr/dlfp/Nautilus/Analyse_Full.png) 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). * __Correctif__ : suite à un [commentaire](https://linuxfr.org/nodes/139923/comments/1997452) du journal dont est issue cette dépêche, il semble possible d'afficher bien plus d'icônes dans une fenêtre de Dolphin. 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 : ![Meilleure vue en liste](http://hugotrip.free.fr/dlfp/Nautilus/Liste48.3.png) ## 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) : ```diff --- a/src/resources/ui/nautilus-window.ui +++ b/src/resources/ui/nautilus-window.ui @@ -200,7 +201,7 @@ - max-width: 682sp + max-width: 750sp True True True ``` Ça marche facilement, mais ça déplace en bas de fenêtre les boutons d'historique et de réglage de la vue. ![une fenêtre qui s'affiche sans barre latérale mais avec une barre d'outils en bas](http://hugotrip.free.fr/dlfp/Nautilus/Nautilus-Threshold.png) 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](https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/) 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 : ```diff --- a/src/resources/ui/nautilus-window.ui +++ b/src/resources/ui/nautilus-window.ui @@ -101,6 +56,7 @@ False False + False 240 px 0.2 ``` 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 : ![une fenêtre qui s'affiche sans barre latérale mais avec une barre d'outils en bas](http://hugotrip.free.fr/dlfp/Nautilus/Nautilus-Show_sidebar.png) Après m'être gratté un peu la tête, en utilisant l'excellent outil [GTK Inspector](https://developer.gnome.org/documentation/tools/inspector.html), je constate que les fichiers sont dans des 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 : ```diff --- 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; } ``` ![une fenêtre qui optimise la zone d'affichage](http://hugotrip.free.fr/dlfp/Nautilus/Nautilus-padding.png) 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é, puisqu'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` : ```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 : ```c #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 : ```bash apt source nautilus ``` Que je peux recompiler en paquets `.deb` ensuite avec la commande : ```bash debuild -b -uc -us ``` Malheureusement les tests exécutés durant la construction échouent chez moi : ```bash 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 : ```bash 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](https://www.debian.org/doc/manuals/maint-guide/modify.fr.html) d'empaquetage de Debian comment mettre en place des patchs. Je mets en place `dquilt`, que j'utilise ainsi : ```bash #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 : ```bash 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` : ```diff 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 @@ 240 px 0.2 + False .close { background-image: radial-gradient(#bf616a, #bf616a 48%, transparent 48.5%); } ``` ![Prêt pour Trixie](http://hugotrip.free.fr/dlfp/Nautilus/Nautilus-OK.png) ### 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écessiter 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](https://discourse.gnome.org/t/how-to-hide-nautilus-or-gnome-files-sidebar/20352) de 2024, c'est un des membres de l'équipe GNOME qui met les pieds dans le plat. * 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](https://discourse.gnome.org/t/hide-nautilus-sidebar/29280/2) 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 jeter tout aux orties.