GNOME Stop Me Now

Posté par  . Édité par BAud. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
50
14
août
2025
Gnome

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/

Sommaire

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, 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 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, 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).
animation montrant le masquage automatique de la barre latérale
Source de l'image : debugpoint.com - CC-BY-SA

  • 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, 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é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 ...

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 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.

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

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 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

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.
une fenêtre qui s'affiche sans barre latérale mais avec une barre d'outils en bas

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 :
une fenêtre qui s'affiche sans barre latérale mais avec une barre d'outils en bas

Après m'être gratté un peu la tête, en utilisant l'excellent outil GTK Inspector, 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 :

--- 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
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 :

    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 intervention à 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 et 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 Thème 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 .

En revanche, choisir le sélecteur headerbar ne 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%);
}

Prêt pour Trixie

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 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 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.

Aller plus loin

  • # Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

    Posté par  . Évalué à 10 (+21/-13).

    … ne plus utiliser gnome.

    Honnetement … il y a eu un journal ou un lien dernièrement qui parlait d'enshitification, et cet article ne parlait que du monde proprio, mais le libre a aussi sa palanquée de trucs qui se sont emmerdifiés avec le temps, l'un des principaux étant Gnome, mais aussi systemd, en voulant remplacer certains trucs historiques par sa propre implémentation qui marche beaucoup moins bien (exemple : remplacement de ntpd ).

    • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

      Posté par  . Évalué à 4 (+6/-3).

      +1

      Un bel effort d'analyse et de persévérance, un journal intéressant.
      Mais je dois dire que cela me fera pas basculer à Gnome.
      Pour moi, c'est Cinnamon ou XFCE.

      • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

        Posté par  (site web personnel) . Évalué à 6 (+5/-1).

        De mon côté, je n'arrive pas à m'en séparer… Cela fait 3 mois que je me suis également mis kde : tout va bien, il est très pratique, fonctionnel, etc. mais je préfère utiliser gnome sans m'expliquer pourquoi.
        Je garde également un oeil sur cosmic qui manque encore de fonctionnalités et peut être de stabilité mais que je trouve encore plus agréable à utiliser pour les tâches courantes que gnome.

      • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

        Posté par  (site web personnel) . Évalué à 10 (+8/-1).

        Perso, même si cela fait belle lurette que je n'utilise plus d'environnement de bureau, je propose systématiquement à mes proches MATE ou Cinnamon. En effet, j'ai constaté que les changements successifs de Gnome cassent leurs habitudes à chaque mise à jour majeure de Debian¹, et que des utilisateurs ordinaires préfèrent la stabilité d'usage.

        Notes :

        1. Ce serait pareil sur n'importe quelle distro, c'est juste que j'installe ce que je connais pour mes proches.

      • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

        Posté par  . Évalué à 4 (+7/-5).

        -1

        Gnome & systemd fonctionnent parfaitement pour mon utilisation. Et puis n'est-ce pas un parfait exemple de l'intérêt du logiciel libre ? Le modifier pour l'adapter à ses besoins ? C'est spécial de dire à un libriste qui use de ses libertés qu'il n'avait qu'à aller voir ailleurs.

        • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

          Posté par  . Évalué à 4 (+8/-6).

          Gnome & systemd fonctionnent parfaitement pour mon utilisation

          Gnome est bien connu pour passer son temps à casser la compatibiité entre les diverses versions de ses API. Beeaucoup d'applis Gnome passsent lleur temps à "évoluer" en supprimant des fonctionnalités. Systemd passe son temps à tout recoder (DNS, Date/time, etc …) pour des trucs qui marchent moins bien que les applis qu'ils sont censés "remplacer" Et le problème avec systemD, c'est que tu ne peux pas virer ces trucs : tu es juste contrant de les désactiver quand tu ne veux pas t'en servir, et t'es pas à l'abri d'une réactivation sans prévenir à la prochaine mise à jour. Donc ouil l'enshitifcation est bien présente dans le logiciel libre.

          C'est spécial de dire à un libriste qui use de ses libertés qu'il n'avait qu'à aller voir ailleurs.

          Mais il fait ce qu'il veut, je ne force ni n'empeche rien. Par contre je peux très bien penser et dire que c'est beaucoup de temps pour pas grand chose d'une part, et que d'autre part, il n'est pas à l'abri d'un changement de comportement qui fait que tout ce qui a été décrit dans ce doc ne sera plus valable. J'use de ma liberté de enser et d'expression pour l'écrire ici. Tu n'es peut-être pas d'accord, peut-être mêm que le fait que je puisse exprimer une opinion différente de la tienne te dérange mais ça ça m'est égal.

          Et puis n'est-ce pas un parfait exemple de l'intérêt du logiciel libre ? Le modifier pour l'adapter à ses besoins ?

          ouias c'est ce que j'aimerais faire avec suystemd. Je demande pas grand chose, juste pouvoir virer les briques qui ne m'intéressent pas. Mais je ne peux pas le faire simplement parce que celui-ci ainsi que els distributions m'en empêchent. Oui je peux changer de distribution (prévu mais pas encore eu le temps/l'énergie pour le faire) mais je prefererais pouvoir supprimer les trucs qui ne me servent pas pour les remplacer par les trucs dont j'ai réellement besoin sans que SystemD décrete que c'est lui le meilleur, qu'il contrôle tout et force l'activation de ses saletés qui entrent en conflit avec ce que je veux utiliser.

          • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

            Posté par  (Mastodon) . Évalué à 10 (+14/-3). Dernière modification le 14 août 2025 à 19:35.

            Gnome est bien connu pour passer son temps à casser la compatibiité entre les diverses versions de ses API.

            Gnome3 est surtout connu pour ses gens qui ne l'utilisent pas et le critiquent sans vraiment se rappeler pourquoi. Un peu comme pour Gimp.

            Je comprends qu'on puisse avoir été utilisateur heureux de Gnome 2 et d'avoir été perdu à l'arrivée de Gnome 3 parce que le paradigme avait changé complètement et il y avait plein de trucs différents. Mais pour ceux qui n'aiment toujours pas, ça fait belle lurette qu'ils ont Mate et Cinnamon.

            Moi j'ai aussi mal digérer au début ce changement tout comme celui de kde 3 à 4.

            Maintenant ça fait 14 ans que Gnome 3 évolue et je te défies de me prouver en quoi gnome 3 version 48 est pire que la première ou la dixième version de Gnome 3. Ce mythe des fonctionnalités perdues c'est du FUD total parce que moi à chaque fois que j'ai testé une distro qui avait une ou plusieurs versions antérieures à celle livrée sur mes Fedora, je me suis rendu compte que je perdais des fonctionnalités et améliorations ergonomiques auxquelles je m'étais habitué sans m'en rendre compte. Mon seul reproche important c'est que Gnome Settings, Tweak et Extensions soient des applis séparées.

          • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

            Posté par  . Évalué à 4 (+2/-0).

            …juste pouvoir virer les briques qui ne m'intéressent pas. Mais je ne peux pas le faire simplement parce que celui-ci ainsi que les distributions m'en empêchent

            Sur Arch, selon la doc, tu peux remplacer systemd par openrc
            https://wiki.archlinux.org/title/OpenRC
            https://wiki.archlinux.org/title/Init#Configuration

          • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

            Posté par  (site web personnel) . Évalué à 10 (+11/-1).

            Gnome est bien connu pour passer son temps à casser la compatibiité entre les diverses versions de ses API.

            La seule chose que GNOME casse régulièrement c'est l'API de ses extensions, et encore c'est plus stable maintenant.

            Beeaucoup d'applis Gnome passsent lleur temps à "évoluer" en supprimant des fonctionnalités.

            C'est plutôt faux ça en vrai. Il y a eu quelques cas mais comme dans tout logiciel en vrai. La question des fonctionnalité est toujours un compromis entre utilité / effort de maintenance / simplicité d'utilisation. Parfois retirer une fonctionnalité peu utilisée mais qui complique la vie des utilisateurs ou des développeurs c'est la meilleure chose à faire.

            Systemd passe son temps à tout recoder (DNS, Date/time, etc …) pour des trucs qui marchent moins bien que les applis qu'ils sont censés "remplacer" Et le problème avec systemD, c'est que tu ne peux pas virer ces trucs : tu es juste contrant de les désactiver quand tu ne veux pas t'en servir, et t'es pas à l'abri d'une réactivation sans prévenir à la prochaine mise à jour.

            Je me sers de systemd tous les jours à la maison et au travail et c'est un bonheur par rapport à avant. Et mon boulot c'est de maintenir des firmware donc des "distro maison".

            Alors oui ce n'est pas parfait mais on est loin du portrait que tu dresses.

            Donc ouil l'enshitifcation est bien présente dans le logiciel libre.

            L'emmerdification c'est valoriser le bilan financier de l'entreprise au détriment des utilisateurs.
            systemd et GNOME ne sont pas dans ce cadre, ils font des choix qui conviennent à énormément de monde mais bien sûr pas à tous.

            Perso j'ai aimé GNOME 2, mais j'adore encore plus GNOME 3. C'est vraiment mon environnement idéal. Et j'en connais plein qui partagent le même point de vue.

            Mais je trouve ça super que pour certains Xfce, KDE ou autre est la meilleure solution. C'est l'avantage du libre, on a le choix. Un logiciel unique ne peut pas satisfaire tout le monde à la perfection.

            ouias c'est ce que j'aimerais faire avec suystemd. Je demande pas grand chose, juste pouvoir virer les briques qui ne m'intéressent pas.

            Tu peux, mais après si la distro ne le propose pas le soucis est la distro et pas systemd.

            • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

              Posté par  (site web personnel) . Évalué à -1 (+2/-5).

              Le commentaire de totof2000 est typique des gens qui n'utilisent ni GNOME ni Systemd mais qui ont lu sur le web que c'était moins bien qu'avant.

              Parce que l'argument fonctionne avec tous les logiciels en fait, Firefox a changé dernièrement beaucoup de choses qui cassaient mon "workflow", ben je me suis adapté, c'est la vie.

              Et pour Systemd, les gens qui disent ça sont toujours des gens qui ne l'utilisent pas vraiment. Parce que comparer systemd-timesyncd avec ntpd, ça prouve juste que tu n'as rien compris.

        • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

          Posté par  . Évalué à 3 (+3/-2). Dernière modification le 14 août 2025 à 20:38.

          Et puis n'est-ce pas un parfait exemple de l'intérêt du logiciel libre ? Le modifier pour l'adapter à ses besoins ?

          Question possibilités et facilités de modifications, l'exemple de Gnome n'est pas convaincant. Que de complications, tout cela pour rester dans un environnement de bureau limité, qui évolue lentement et surtout très gourmand en ressources si l'on considère le service rendu. À tant qu'à faire, si l'on a envie d'adapter, de bidouiller, d'explorer, d'autres solutions d'avenir existent. Pour moi c'est l'environnement Hyprland, bien documenté, dont le développement avance à la vitesse grand V mais il n'est pas le seul sur ce créneau.

          • [^] # Re: Il y a quand même un moyen bien plus efficace pour éviter de se fatiguer à tout ça ....

            Posté par  . Évalué à 3 (+3/-2).

            Question possibilités et facilités de modifications […] Si l'on a envie d'adapter, de bidouiller, d'explorer […]

            L'OP n'a pas dit qu'il cherchait ni la facilité ni à explorer… Juste à garder Gnome mais adapter son Nautilus. Cette manie du "dis moi ce dont tu as besoin je te dirai comment t'en passer" c'est très LinuxFR.

            un environnement de bureau limité, qui évolue lentement et surtout très gourmand en ressources

            • Limité : non. Il fait ce que je lui demande, je peux le piloter aisément au clavier, ça me va.
            • Évolue lentement : Comme toi je suis sous Arch donc mes applis sont fraîches mais j'aime que mon bureau reste stable. Depuis plusieurs années c'est le cas sous Gnome. Ça juste marche, sans se mettre en travers de mon chemin.
            • Très gourmand en ressources : légende urbaine. Si j'ai des soucis de RAM ça ne sera jamais de la faute de Gnome, ça viendra plutôt du browser (quelqu'il soit d'ailleurs). Et puis je ne suis pas sur un EEE. Après 10 ans de OpenBox (difficile de faire plus léger) je voulais un DE batteries included et Gnome répond parfaitement au besoin.

            Pour moi c'est l'environnement Hyprland

            Félicitations. Ça n'est absolument pas comparable à Gnome puisque ce n'est qu'un compositeur. J'ai justement quitté Openbox parce que j'en avais assez de gérer les trucs à installer pour des fonctionnalités basiques (launcher, systemtray, tint2, screenshot, …). Donc j'aurai les mêmes soucis avec Hyprland mais ça c'est parce que je ne cherche pas plus un DE à bidouiller. Je bidouille autre chose.

  • # alternatives...

    Posté par  . Évalué à 2 (+4/-2).

    Pareil, pourquoi s'épuiser à nager à contre-courant alors que d'autres propositions existent. Si tu cherches de la configuration qui permette que ton système s'adapte à tes envies KDE est idéal.

    • [^] # Re: alternatives...

      Posté par  (Mastodon) . Évalué à 6 (+3/-0).

      Comme l'auteur je suis un grand fan de la touche unique qui fournit une fonctionnalité multiple de lanceur d'application, recherche, liste et visualisation des fenêtres ouvertes et je n'ai jamais réussi à configurer KDE pour faire de même et aussi bien et du coup je reviens toujours à Gnome3.

      Comme quoi chaque projet a ses limitations.

  • # choix de distro

    Posté par  (Mastodon) . Évalué à 4 (+1/-0).

    Comme mentionné tardivement dans le journal du même nom je trouve le choix de Debian assez curieux venant de Fedora.

    Oui le cycle de vie d'une Debian est bien plus lent (2 ans entre versions stables, 5 ans de support complet) mais reste plus rapide que par exemple une distro basée sur RHEL comme Almalinux qui assure 10 ans de mises à jour de sécurité tout en restant plus proche de Fedora en terme de gestion, système de packaging, etc.

    Il y a une époque où la vétustée des paquets de la distrib étaient un problème pour ce genre de distros en fin de cycle, mais avec flatpak, toolbox, distrobox et/ou nix, il est désormais hyper facile d'installer des applications dans leur dernière versions sans toucher au socle de base ni risquer de casser son système. Si on n'est pas gamer et qu'on n'a pas besoin des toutes dernières versions de certains drivers pour du matériel particulier, il n'y a plus vraiment de mauvais point.

    • [^] # Re: choix de distro

      Posté par  . Évalué à 3 (+1/-0).

      Au moment de ma migration, je me suis posé la question des dérivées de RHEL, mais elles étaient toutes jeunes, et donc j'étais moins certain de leur pérennité.

  • # changer la taille des icônes ?

    Posté par  . Évalué à 2 (+1/-0).

    N'était-il pas plus simple de juste changer la taille des icônes ? C'est à disposition dans le menu. Je n'ai jamais rencontré ce problème de 9 icônes sur mon écran (qui a une taille on ne peut plus standard).

    Sinon, comme indiqué par d'autres, il suffit d'utiliser un autre gestionnaire de fichiers. Ce n'est pas ça qui manque. Et pas besoin de changer de gestionnaire de bureau pour cela.

    • [^] # Re: changer la taille des icônes ?

      Posté par  . Évalué à 2 (+0/-0).

      Je voulais conserver au maximum mes habitudes : https://linuxfr.org/news/gnome-stop-me-now#toc-418-im-a-teapot

      • [^] # Re: changer la taille des icônes ?

        Posté par  . Évalué à 1 (+0/-0).

        Avec ta taille de fenêtre et la taille par défaut des icônes, j'ai 5 colonnes et 4,5 lignes. Aucune idée par contre si les icônes font 64 pixels, mais elles sont déjà bien grosses. Et je ne sais pas comment tu calcules tes pourcentages.
        Le volet de gauche semble se rétrécir au minimum à la longueur du texte "Dossier personnel".

        • [^] # Re: changer la taille des icônes ?

          Posté par  . Évalué à 2 (+0/-0).

          Pour déterminer le nombre d'icônes affichées, j'utilise le répertoire de test montré dans mes screenshots : les noms de fichiers prenaient alors 2 lignes. La différence vient peut-être de là.

          Sinon, mes pourcentages correspondent au ratio des surfaces du rectangle de la zone de contenu sur celui de la fenêtre (longueur * largeur, en pixels)

  • # Bravo, felicitation

    Posté par  . Évalué à 10 (+16/-1).

    De ma part, un petit mot pour féliciter - au delà de la partie technique que je ne peux pas évaluer, bien trop complexe pour moi- l'esprit de ce texte.
    Je trouve rafraichissant, rassurant et agréable l'esprit positif et constructif apporté !
    Ca me donne foi dans le libre !!! On n’a presque l’impression qu’on peut être autodidacte facilement :p

    Alors, certes, en ce qui me concerne, n'ayant pas la capacité technique la capacité de le faire (et soyons honnête, un problème pileux dans les paumes), j'aurais probablement essayé un autre gestionnaire… Mais ici, je salue la persévérance constructive !

    Merci pour ce billet pas « utile » pour moi, mais TRES plaisant !

    • [^] # Re: Bravo, felicitation

      Posté par  . Évalué à 3 (+2/-0).

      Pareil, je trouve ça vraiment très sympa à lire comme dépêche.

      Bien que cela soulève un problème de fond dans la philosophie des équipes Gnome/Nautilus, cela montre aussi à quel point le libre permet de faire ce que l'on veut si on est prêt à y mettre du sien.

      C'est une différence fondamentale par rapport aux logiciels propriétaires pour lesquels l'utilisateur motivé (et un minimum compétent il faut l'avouer) est totalement coincé.

      Là, même si cela a coûté des efforts, tu es arrivé à tes fins et c'est chouette !

      • [^] # Re: Bravo, felicitation

        Posté par  . Évalué à 1 (+1/-2).

        Le problème c'est qu'ils sont capables de casser le comportement de leur truc du jour au lendemain sans prévenir, et tout le temps et l'énergie que tu aura mise à tatonner, à t'adapter, et à écrire un journal ou une doc n'aura servi à rien …

        • [^] # Re: Bravo, felicitation

          Posté par  (Mastodon) . Évalué à 10 (+12/-0).

          C'est le cas de n'importe quel dev. Les seuls softs qui n'ont pas ce risques sont ceux qui sont abandonnés.

          Le xkcd qui convient:

          xkcd 1172 workflow

          • [^] # Re: Bravo, felicitation

            Posté par  . Évalué à 3 (+3/-0).

            Cependant, gtk avait l'avantage de permettre de personnaliser facilement l'apparence des applications et il existait des centaines de thèmes. Avec libadwaita, toute cette liberté qui était, selon moi, une grande force de l'écosystème linux a été réduite à néan.

            • [^] # Re: Bravo, felicitation

              Posté par  (site web personnel) . Évalué à 2 (+1/-0).

              À ce sujet, voir le fork qui a été fait de libadwaita par Clément Lefebvre (Linux Mint) : libadapta.

            • [^] # Re: Bravo, felicitation

              Posté par  . Évalué à 5 (+4/-0).

              Non, gtk est indépendant de libadwaita qui n'est qu'une surcouche de personnalisation dédiée à gnome.
              Personne n'est obligé de l'utiliser et les environnements de bureau utilisant gtk sont au contraire invités à développer leur proche surcouche s'ils le veulent. Cette séparation gtk / libadwaita est justement pour éviter les frictions.

            • [^] # Re: Bravo, felicitation

              Posté par  (Mastodon) . Évalué à 2 (+1/-0).

              s/ecosystème linux/ecosystème gnome/g

              KDE reste extrèmement configurable. J'ai basculé vers KDE il y a un an et demi environ, à cause de libadwaita et du fait qu'à chaque mise à jour de gnome, les deux ou trois (pas plus) extensions gnome que j'utilisais cassaient. A chaque fois.

              Je ne regrette vraiment pas Gnome. KDE Plasma6 est vraiment bien fini, très adaptable (mais rien n'oblige à adapter, la config par défaut juste marche(TM)), et rien de ce que j'aimais dans Gnome ne manque dans KDE.

              En plus pas de megacorp US derrière, des humains (plutôt allemands) et un véritable esprit logiciels libres que Gnome a selon moi perdu dans sa volonté de cloner MacOS et de mater ses utilisateurs.

              • [^] # Re: Bravo, felicitation

                Posté par  . Évalué à 2 (+1/-0).

                J'apprécie aussi kde, malheureusement le bureau me donne toujours une sensation de moindre fluidité qu'avec gnome (sur mon vieil ordinateur). Je ne sais pas d'où cela peut venir.

                Plus d'utilisation mémoire aussi, mais pas tellement non plus (l'écart est < à 500Mo par rapport à gnome).

                Peu de bindings (officiels) aussi pour programmer avec autre chose que du C++. Mais je rajoute rarement une interface graphique à mes expérimentations de toute façon. C'est tellement pénible.

                Et sans doute quelques détails ici ou là qui me font retourner à gnome (connexion facile à distance intégrée à gdm?). Peut-être aussi un peu plus d'utilisation d'applications gtk que qt, mais je ne dois pas être loin de 50/50.

                Je dirais pour moi peu importe gtk ou qt (ou autre), c'est un détail technique pour le développeur pas l'utilisateur, l'important est le résultat final : interface utilisateur satisfaisante sans se prendre la tête + fonctionnalités attendues qui juste marchent.

                Quel gestionnaire de connexion utilisez-vous avec kde ?

  • # So Windows

    Posté par  (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 15 août 2025 à 09:28.

    Je n'utilise que rarement le panneau des raccourcis (F9), tous mes dossiers usuels ayant des raccourcis sur le bureau.

    C'est marrant c'est un truc que je continue à faire au boulot sous Windows et qui pourtant ne me manque pas sous GNOME (je crois que mon vrac y est +/- dans Téléchargements)

    • [^] # Re: So Windows

      Posté par  (site web personnel) . Évalué à 3 (+1/-0).

      Y'a des gens qui mettent leur vrac dans "Trash" :-)

      Et qui pleurent lorsqu'un admin-sys a fait "Vider la corbeille" pour gagner un peu de place sur leur disque full.

      Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: So Windows

      Posté par  . Évalué à 2 (+0/-0).

      Mon vrac est +/- dans Téléchargements aussi.
      Ce sont des raccourcis de certains dossiers qui sont sur le bureau : ils remplacent plutôt le contenu du volet latéral de Nautilus.

  • # Nemo

    Posté par  (site web personnel) . Évalué à 4 (+3/-0).

    Ça fait des années justement que je remplace systématiquement Nautilus par Nemo comme gestionnaire de fichiers par défaut pour gnome… Pour le reste, tout me vas, mais la simplification à l'extrême de nautilus et changement d'usage, casse ma productivité…

    Au quotidien, ça me cassait autant les pieds que la perte du drag&drop entre file-roller et nautilus/nemo à cause d'une regression de Wayland par rapport à Xorg…

    • [^] # Re: Nemo

      Posté par  (site web personnel) . Évalué à 2 (+0/-0).

      J'ai entendu parler de cette histoire de file-roller.

      Une régression ? Le drag-drop marche très bien sous Wayland comme le prouve cet exemple (vidéo ici).

      De ce que j'ai entendu, c'est pas plutôt qu'à la place de le gérer différemment sous X.org et Wayland (car l'API est différente ou GTK gèrerait mal cette différence), ils l'ont désactivé comme les gros clichés de développeurs GNOME qu'ils sont ;-) ?

    • [^] # Re: Nemo

      Posté par  . Évalué à 3 (+1/-0).

      Ah je ne suis pas le seul que ça énerve cette disparition du glisser/déposer avec FileRoller et Nautilus.
      C'est assez hallucinant que l'on ne puisse pas faire ça en 2025 …

      • [^] # Re: Nemo

        Posté par  (site web personnel) . Évalué à 2 (+0/-0).

        Je pourrais regarder ça, mais par contre ce serait dans les distros Linux que j'utilise (RHEL 9-10).

        En admettant que je trouve, je pourrais vous filer le patch ; ce serait à vous de l'appliquer (je peux aider sur les détails, j'ai patché des paquets Debian y a longtemps).

        Vous en pensez quoi ?

  • # XFE

    Posté par  . Évalué à 1 (+2/-2).

    Ici : http://roland65.free.fr/xfe/

    Récemment mis à jour en version 2.1. Rapide, léger et malgré tout puissant…

  • # De l'intuitivité et de la simplicité comme prêt-à-penser… euh… prêt-à-refaire

    Posté par  (site web personnel) . Évalué à 7 (+5/-0).

    Merci pour cette plongée au sein des mécanismes d'évolution de gnome.

    Depuis longtemps (probablement 10 ans) et plus particulièrement depuis gnome3, le projet est très "appleisé": Rendre plus simple en enfouissant les fonctions.

    Il y a plusieurs années, lors de discussion de stand (JDLL), je m'étais fait remonter les bretelles car je regrettais qu'on ne puisse pas avoir de menu dans de plus en plus de fenêtre d'application, seulement des boutons icônes en nombre très limités pour ouvrir des sous-menus. Une logique très tactile… mais nos moniteurs d'ordinateur ne sont toujours pas devenus tactilement très pergo-ratiques, les tablettes et les téléphones sous gnome ne sont pas légions…

    Les types m'avaient aussi dit que c'était intuitif… Par exemple à l'époque sur le dockage des fenêtres aux côtés du moniteur… J'avais qu'à lire la doc…

    Ok mais la culture de la simplification n'était pas seulement cantonnée à l'apparence, mais aux applications elles-même, plus exactement à leur nom.

    Car dans l'article on parle de Nemo ou de Nautilus… Mais dans l'interface ça s'appelle "Fichiers" et le gestionnaire de disque "Disques", pour aller sur le web "Web"…
    Réponse : Parce que "Madame Michu s'en fiche du nom elle veut la fonction, la tâche principale"… (Entre nous d'abord, pourquoi "Madame") …

    J'en reste dubitatif, car pas si simple de trouver peu de documentation sur les applications Gnome sur internet (sachant que la doc officielle est incomplète et pas systématiquement en français - pauvre famille Michu)?

    Tentez par exemple "Comment changer les icônes de Fichiers"? "Comment formater un disque avec Disques?"…

    Résolument, je trouve difficile de (re)venir vers Gnome dont la culture de la simplification et de l'intuition, peut ressembler à une culture de l'invisibilisation des détours de la pensée. Si on évolue pas avec la logique du projet, ça devient une chorégraphie de raccourcis et gestes mystiques.

    Merci aux projets qui pensent des usages flexibles (simplifié/novice, Spécialiste, Autonome et personnalisable)

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.