La remise à plat de GNOME avec la ré-écriture qui a produit GNOME 3 a fait couler beaucoup d'encre. La première impression reçue à l'utilisation est que les possibilités de personnalisation sont très réduites par rapport à « avant ». Cependant, cette impression est fallacieuse. Les possibilités de configuration sont en réalité innombrables mais ne sont pas accessibles par les mêmes méthodes qu'auparavant. GNOME 3 crée un environnement à haut potentiel, favorable à des développements divers qui se mettent à foisonner pour engendrer des solutions et des extensions de tous poils. En particulier, l'utilisateur est confronté à de trop nombreux moyens de configuration qui, d'une part, demandent un apprentissage et, d'autre part, se marchent parfois sur les pieds (et il peut arriver que cela fasse mal).
Ainsi, par exemple, Canonical a créé le genre Unity. L'orientation « tablette » de cet environnement conduira peut-être à un succès évolutif mais, en attendant, l'auteur de cette page n'a pas pu s'y faire sur un PC de bureau.
En attendant que la sélection darwinienne (ne devrait-on pas écrire « darlinienne » ? ;-) fasse le tri dans tout ceci, la présente page étudie s'il est possible de retrouver ses habitudes de travail sans pour autant tourner le dos à l'évolution de la technologie.
Le but de l'exercice suivant est de voir s'il est possible de configurer GNOME 3 avec un gestionnaire de fenêtres évolué, sur une machine courante, assez peu puissante, tout en gardant ses habitudes de travail antérieures :
Les premiers essais effectués ont mis en œuvre GNOME Shell (soit en français le « manteau* du GNOME »), avec l'extension officielle « dock ». Celle-ci a fait écrire à Linus Torvalds qu'elle rendait GNOME 3 presque utilisable [sic]. Malheureusement, ce dock ne permet pas de distinguer très facilement les applications en cours et les lanceurs et, à l'usage, il s'avère peu commode.
Pour faire mieux, il est possible de greffer sur le manteau du GNOME (GNOME Shell) une excellente application dite Cairo-Dock. Celle-ci interagit assez profondément avec le système, ajoutant ses propres éléments, remontant notamment aussi au niveau du gestionnaire de cession et pouvant utiliser compiz ou metacity comme gestionnaire de fenêtres, selon le choix fait par l'utilisateur au chargement de la session.
La capture de l'écran total suivante montre que, du point de vue du principe, l'objectif peut alors être atteint. La barre noire
supérieure du Shell, en général inutile, libère l'espace en étant escamotable ; le panneau des lanceurs, à gauche,
et la barre des tâches, en bas, sont fixes pour éviter les animations intempestives lorsque la souris s'égare ; le
sélecteur de bureau fonctionne, affiche le numéro de l'espace de travail en cours d'utilisation et, au survol, affiche le
nom (personnalisé) de l'espace survolé. Les icones des instances d'applications sont regroupées au milieu en bas et identifiées
par une étiquette qui apparait au survol. On a aussi placé à droite, en bonus, les principaux dossiers utiles, avant l'icone
de déconnexion et le bouton d'assistance.
La solution semblant si proche, il est décevant de constater que, malgré la désactivation de la plupart des effets graphiques, l'utilisation de cette configuration est poussive, le système est très peu réactif, même vis-à-vis de demandes simples comme un changement d'application par [Alt][Tab] ou l'ouverture de la ligne de commande par [Alt][F2]. Une grande « marge de progression » reste donc ouverte à cet égard.
La configuration ci-dessus est obtenue grâce à l'installation et au paramétrage de deux extensions, avec les étapes suivantes.
.Par défaut, GNOME Shell gère les bureaux (espaces de travail) de façon dynamique. C'est-à-dire que si l'utilisateur travaille sur un seul bureau, le Shell met à sa disposition un deuxième bureau vide « au cas où ». Si l'utilisateur, jugeant son bureau trop encombré, déplace sur ce deuxième bureau une fenêtre d'application, le Shell crée un troisième bureau vide « au cas où » . Cette disposition « intelligente » conduit à avoir toujours un bureau inutilisé et n'incite pas l'utilisateur à organiser son travail a priori.
L'auteur de cette page a pris des habitudes de travail reposant sur 4 bureaux utilisés avec une organisation peut-être pas idéale mais souple et « à sa main » : (1 = haut-gauche) métier (photo), (2 = haut-droite) correspondance, (3 = bas-gauche) divers autres souvent de courte durée de vie, (4 = bas-droite) applications en tant que superutilisateur.
Pour répondre à ce besoin, l'éditeur de configuration de GNOME dconf-editor peut d'abord
être mis à contribution pour désactiver la gestion dynamique des espaces de travail
par le Shell (décocher la clef org.gnome.shell.overrides.dynamic-workspaces)
et régler à 4 le nombre d'espaces de travail dont GNOME confie la gestion au gestionnaire de fenêtres (window manager ou wm,
d'où mettre la clef org.gnome.desktop.wm.preferences.num-workspaces à 4) :
.
Au moment où ce paramétrage est appliqué, l'application cairo-dock affiche par défaut les quatre espaces de travail sous la forme d'une grille cliquable 2x2. Malheureusement, le gestionnaire de fenêtres considère toujours que les bureaux sont sur une seule colonne et donc le raccourci clavier permettant de changer de bureau est [Ctrl][Alt][Flèche haut ou bas] par défaut.
Dans cairo-dock, par un clic droit sur la sélecteur de bureau puis le choix de Sélecteur de bureau > Editer,
il est possible de paramétrer l'icone du sélecteur. Par exemple, il est facile de nommer les espaces de travail :
.
Cela fait, il resterait à régler la façon dont le gestionnaire de fenêtres organise les espaces de travail, en matrice 2x2 et non en colonne 1x4 mais cela ne saute pas aux yeux.
Ainsi, du point de vue de la logique d'organisation du travail, la configuration ci-dessus répond à peu près au besoin. Cependant, l'exécution demande des ressources significatives, sans doute en raison d'une certaine lourdeur du gestionnaire de fenêtres, et, par ailleurs, utiliser un gestionnaire de fenêtres capable des effets les plus décoiffants et y désactiver tous les effets est une démarche peu cohérente. En définitive, après quelques essais (voir, en bas de cette page, la table comparative des configurations testées), la conclusion, à ce jour, est que l'utilisateur recherchant l'efficacité est devant l'alternative suivante :
Cela dit, les évolutions sont rapides et cette conclusion n'est sans doute que provisoire... En attendant, la machine de production de l'auteur de cette page va rester sous Lucid Lynx.
Cette annexe compare les environnements testés sous Ubuntu 12.04 LTS alias "Pangolin Précis", avec OpenGL accepté.
Dans tous les cas, la version de GNOME est la même. Ceci a été vérifié par la commande :
$ gnome-session --version
qui répond :
gnome-session 3.2.1
La commande env affiche les variables d'environnement système. Seules les variables de la table suivante varient. Les deux dernières lignes de la table indiquent également un commentaire éventuel et le gestionnaire de fenêtres en cours, obtenu en recherchant unity, shell, metacity et compiz par une commande pgrep. Exemple :
$ pgrep -l compiz
1750 compiz
La table suivante compare les caractéristiques des environnements essayés.
Session Variable |
GNOME | GNOME classique | GNOME classique (sans effets) | Ubuntu | Ubuntu 2D | Cairo-Dock (GNOME avec effets) | Cairo-Dock (GNOME sans effets) | Cairo-Dock (avec tableau de bord Unity) |
|---|---|---|---|---|---|---|---|---|
| DESKTOP_SESSION | gnome-shell | gnome-classic | gnome-fallback | ubuntu | ubuntu-2d | cairo-dock | cairo-dock-fallback | cairo-dock-unity |
| GDMSESSION | gnome-shell | gnome-classic | gnome-fallback | ubuntu | ubuntu-2d | cairo-dock | cairo-dock-fallback | cairo-dock-unity |
| XDG_CURRENT_DESKTOP | GNOME | GNOME | GNOME | Unity | Unity | GNOME | GNOME | GNOME |
| Commentaire | Fenêtres sans bordures. Cairo inutile. | Cairo, inutile, crée un gros masque noir. | Fenêtres sans bordures. | Cairo crée un gros masque noir. | ||||
| Gestionnaire de fenêtres | gnome-shell | compiz | metacity | compiz avec unity-panel-service | metacity avec unity-2d-shell, unity-2d-panel et unity-panel-service | compiz | metacity | compiz avec unity-2d-panel et unity-panel-service |
unity-panel-service est le programme pour tracer le tableau de bord associé au manteau* de Unity. Il est normalement lancé automatiquement par le manteau de Unity (qui démarre en tant que module de compiz) et il est utilisé pour tracer les panneaux qui peuvent ensuite servir à présenter le menu global ou des indicateurs.
unity-2d-shell est le manteau* de Unity. Il contient le lanceur
et la barre. Il fonctionne en tant qu'élément de Unity 2D et n'est pas destiné à fonctionner isolément.
Cependant, son lancement par
unity-2d-shell [-opengl] [-rootqml File.qml]
affiche quelques composants de Unity 2D. Il peut être utilisé pour le test ou le
prototypage de seulement quelques éléments spécifiques de Unity 2D grâce à l'argument
rootqml.
unity-2d-panel est le tableau de bord de Unity 2D. Il affiche un panneau supérieur contenant le menu application et des indicateurs. C'est un élément de Unity 2D non conçu pour tourner isolément.
* Le mot « manteau » est l'une des traductions de « shell » pris dans son sens de couche extérieure contenant des éléments divers.