Non French speaking visitors : an English version of the article is available here.
Depuis un certain temps, les icônes du bureau Gnome de mon portable professionnel (Ubuntu 10.04) n’étaient plus affichés, sans que la raison n’en soit évidente. Après avoir essayé toutes les suggestions proposées sur le Web, j’ai fini par laisser tomber, car après tout il n’y a pas mort d’homme, même si c’est parfois pénible.
Mais comme il est frustrant de s’avouer vaincu par un tas de plastique et de silicium, on a remis le couvert ces derniers jours afin de tordre le cou au problème. Et on y est arrivé ;)
Tout tourne autour des settings de Nautilus (l’équivalent de Explorer de Windows - le File Explorer, pas Internet Explorer). Les diverses solutions proposées çà et là indiquent d’aller modifier via gconf-editor le paramètre apps/nautilus/preferences/show_desktop qui spécifie si Nautilus doit afficher ou non les icônes sur le bureau (qui ne sont autres que les objets présents dans le dossier $HOME/Desktop). Dans ma configuration, ce paramètre est à false, ce qui explique que les icônes ne sont pas affichées. Tout cela est logique finalement.
Ca sonne bien, sauf qu’ici toute tentative d’édition de ce paramètre est bloquée par une indication comme quoi il n’est pas modifiable. Même en essayant de forcer la main par des manips dont je ne me rappelle plus le détail, la valeur false revenait après login.
A force d’essayer sans succès tout ce qui était suggéré, j’ai essayé de comprendre comment ces paramètres sont stockés. En fait, c’est très simple : tout est dans un dossier nommé $HOME/.gconf. Notez le "." en tête du nom, qui rend le dossier invisible lors d’un ls standard, ou sous Nautilus, sauf à cocher l’option "afficher les fichiers cachés". On retrouve sous ce répertoire l’arborescence qui s’affiche sous gconf-editor, les éléments terminaux étant à chaque fois dans un unique fichier nommé %gconf.xml situé dans le répertoire qui constitue le dernier niveau de la branche. Armé de cette information, on retrouve sans problème le setting de show_desktop, qui est d’ailleurs à true à ma grande surprise. Cela veut donc dire que quelqu’un vient écraser ce paramétrage après coup, et ce ne peut être qu’un autre fichier de configuration.
On part donc à la recherche de tout ce qui s’appelle gconf de près ou de loin sur le système, le moyen le plus simple étant sudo find / -type f -name "%gconf*" (la selection du pattern du nom de fichier est basée sur les noms que j’ai rencontrés lors de mes recherches). On en trouve dans :
– le répertoire personnel, sous .gconf, comme déjà mentionné
– /var/lib/gdm
– /var/lib/gconf
– /etc/gconf
ATTENTION : cette liste peut dépendre de votre configuration, des applications installées,... Par exemple, je ne sais pas à quoi correspond ce qui est sous /var/lib/gdm
Deuxième étape, trouver si un de ces fichiers contient show_desktop quelque part. Ici, grep est ton ami, surtout si vous avez pris la peine de sauvegarder le résultat de find dans un fichier via une simple redirection. Dans mon cas de figure, on trouve le paramètre dans $HOME/.gconf bien entendu, mais aussi dans /var/lib/gconf, et surtout dans des fichiers résidant dans des répertoires dont le nom se termine par .mandatory. Comme par hasard, l’un d’entre eux contient la valeur false. Changement rapide de cela (en sudo, car le fichier n’est pas modifiable par un utilisateur autre que root), et après logout/login on retrouve nos icônes sur le bureau.
Hourra !!!
Retour sous gconf-editor, et on constate que le setting est bien à true maintenant, mais que le paramètre n’est toujours pas modifiable.
Et si on supprimait (ou plutôt renommait, par sécurité) le répertoire /var/lib/gconf/unity.mandatory contenant le fichier incriminé ? Essai : message d’erreur évoquant un problème de configuration, mais ça marche en ce qui concerne l’affichage des icones et l’accès en read-write au paramètre. C’est alors qu’on se souvient que bon nombre de répertoires ou fichiers gconf trouvé précédemment sont en fait vides. OK, on crée donc un répertoire vide, avec le nom de celui qui nous posait des problèmes. Et là, c’est le Graal : plus de message et plus de problème.
Les explications qu’on peut déduire de tout cela (sous réserve de confirmation), sont que :
– il existe un mécanisme de restriction des configurations faites par l’utilisateur, sous forme de fichiers résidant dans l’arborescence système, et stockés dans des répertoires dont le nom se termine par .mandatory
– ces restrictions sont apportées par des applications ou composants systèmes complémentaires. Dans mon cas, le fichier responsable résidait dans le répertoire nommé /var/lib/gconf/unity.mandatory.
Pour info, si j’ai bien compris ce que j’ai pu lire çà et là, Unity est le nouveau desktop introduit récemment sous Ubuntu, et qui est notamment employé sur les éditions netbook. Il vise à proposer une nouvelle philosophie d’interface, plus simple et plus dépouillée, qui devrait à terme être généralisée à toutes les éditions à compter de la 11.04. Or il semble que ce type de desktop n’affiche aucune icône sur le bureau, pour justement le conserver simple. CQFD
Et comment en sommes-nous arrivés là ? Et bien parce la curiosité étant un vilain défaut, j’ai à un moment donné voulu tester Unity. Il semblerait que son nettoyage lors de la suppression n’était pas complétement finalisé à cette époque-là.
Et maintenant que j’ai bien galéré pour trouver cela, je parie que je vais tomber sur une doc chez Gnome qui explique tout ceci de manière limpide :/ Bon, honnêtement, je n’y crois pas, car je pense que j’aurais trouvé au moins un lien dessus lors de mes innombrables Google-sessions.
English version
Since a while, the desktop of my Ubuntu 10.04/Gnome laptop doesn’t show icons anymore. I’ve tried all the solutions I could find on the Web, but no way : they were always defeated by the fact that the show_desktop parameter in Nautilus preferences was shown by gconf-editor as not writable. Even brute force approaches gave no result, the setting being set back to false at next login.
Although not really a harmful problem, this is a bit annoying sometimes. Not being rescued this time by our good old friend Goggle, I decided to investigate on my own.
First question : how are all these parameters stored ? The answer is simple once you get accustomed to the commonly used approach : in a hidden directory named .gconf under the home dir of the user. Some greps later, I found the setting in the file $HOME/.gconf/apps/nautilus/preferences/%gconf.xml, in a XML element related to show_desktop. Fine. By the way, the setting there is true, although icons are not displayed.
So it seems that seomone else is overriding this setting, and forcing it to false. But who ? All this mechanism being based on configuration files, there are great chances that some XML file somewhere is containing the same setting, but with false as value, and that this file takes precedence over mine.
A couple of find of gconf related files all over the system exhibit other guys in /var/lib/conf for instance. Delving in the tree leads to several dirs with names ending by .mandatory, one of them being unity.mandatory, containing the file %gconf-tree.xml, itself containging... our beloved show_destop parameter set to "false".
Bingo :)
Start vi (as sudo, since we are in /var/lib), change false to true, save, logout and login back. Yeah, icons are back on the desktop. Problem solved.
Really solved ? Hmmm, not yet unfortunately : if we go back to gconf-editor, the show_desktop Nautilus preference is now set to true, but it is still read-only. So obviously, the fact that a parameter appears in a file in a *.mandatory directory under /var/lib/gconf seems to overide the value set by the user, and makes the parameter read-only.
But what’s the heck with unity ? In fact I have just been victim of my own curiosity :(
Some time ago I gave it a try to see what it was really. But I decided it to remove it after, and the cleanup process was obviously not complete at that time, so this left some configuration files around. And why does Unity force destop icons not to be displayed ? Maybe to keep the user interface the most simple possible, since it is one of its goals.
Okay, so the temptation is great now to delete all the unity.* dirs (more exactly, to move them somewhere else by security). Upon next login, I got a sanity error message related to gconf configuration, but all was running fine apart from this. Maybe a pointer on these configuration data is stored somewhere. How to get rid of this without hunting down the Unity tracks all over the system ?
I then remember that a great number of gconf related directories were empty, or containing and empty XML file. So I tried to put the directories back, but leaving unity.mandatory one empty. Logout/login. All clean now : no error messages, icons still on the desktop and Nautilus show_desktop parameter writable.
Here we are. I admit that it is not a 100% solution (let says 99.9%), since there are still some Unity leftovers, but this is a good compromise "result versus spent time". So final stop :)
I guess that now that I’ve spent all this time on the problem, I’ll find all this clearly detailed in some Gnome documentation :/ But honestly, I’m not that convinced, since it should have been returned by one of the numerous Google sessions I did.
I hope this will help anybody encountering troubles with gconf manipulations. Anyway, it learnt me a couple of things relating to its mechanisms. Not so bad after all ;)