Si je relis les propos que j’ai pu tenir au moment de la sortie de GNOME 3, en 2011, je m’aperçois que mon regard sur cet environnement a beaucoup évolué, sans pour autant que l’essentiel ne change :

• Les bugs ayant disparu, la lourdeur de l’environnement ayant un peu diminué, l’ensemble est devenu utilisable sur une machine moyennement performante.

• Je trouve même l’utilisation agréable et bien conçue quand on est sur un ordinateur mobile ou sur un écran de taille mesurée, avec un clavier sous les doigts.

• Je reste rétif à l’idée d’utiliser cet environnement sur un grand écran 25’ avec une souris : bonjour les gesticulations et la nausée. Du coup, mon ordinateur de bureau est resté sous Mate.

Si donc mon Thinkpad d’occasion se révèle très agréable et fluide sous GNOME 3, la puissance limitée de l’eeePC qui l’a précédé m’a obligé à chercher des solutions plus légères ces dernières années, au point que j’ai pris goût à la puissance et à la simplicité du gestionnaire de fenêtre i3. Cet environnement par pavage de fenêtres est d’autant plus agréable qu’on aime travailler sur le terminal et ne pas utiliser la souris. Il sera parfait pour tous ceux qui préfèrent le gestionnaire de fichiers Ranger à Nautilus (appelé de nos jours platement Fichiers).

Comme j’ai fait en sorte d’utiliser quelques technologies encore expérimentales sur ma nouvelle machine, elle est en Btrfs avec snapshots et en Wayland. Du coup, j’étais particulièrement impatient de voir Sway 1.0 sortir sur Archlinux. En effet, j’avais testé Sway en version 0.15 sur ma machine précédente, mais les bugs étaient encore trop nombreux pour une utilisation quotidienne efficace. Sway est la transposition du projet i3 pour le serveur d’affichage Wayland. Il est principalement développé par Drew DeVault, alias sircmpwn, autre amateur de vieux Thinkpads et adepte d’un minimalisme informatique très cohérent, d’un projet à l’autre.

Tous les problèmes qui avaient rendu l’utilisation de Sway 0.15 peu satisfaisante paraissent aujourd’hui réglés. Les fenêtres flottantes fonctionnent comme elles le doivent et les fenêtres un peu chargées de GTK3 ou de QT5 sont pleinement fonctionnelles. Me restaient tout de même deux problèmes à régler :

• L’un, commun à tous ces environnements minimalistes, était l’intégration de Gnome-Keyring ou d’un autre agent SSH.

• L’autre, commun à plusieurs environnements sous Wayland, était le bon fonctionnement de Smplayer.

Pour Smplayer, le problème était que la vidéo ne démarrait pas et affichait une erreur assez peu explicite, signifiant en fait qu’il essayait en vain d’ouvrir X11, lequel n’étant pas installé se révélait peu disponible. En ajoutant en option à passer à mpv dans les paramètres avancés --gpu-context=wayland le problème disparaissait. Reste que la vidéo démarrait dans une fenêtre séparée avec un ratio déformant. Si on accepte l’idée d’avoir deux fenêtres séparées (une pour Smplayer avec ses menus et commandes) et une pour la vidéo, le problème de ratio se règle en demandant explicitement à Smplayer d’exécuter mpv dans sa propre fenêtre, toujours dans les paramètres avancés.

Pour Gnome-Keyring, j’ai pataugé un peu plus longtemps. La page du wiki d’Archlinux consacrée à ce problème est assez touffue, mais elle ne donne pas la solution exacte du problème, car les variables d’environnement sont un peu retorses avec Wayland :

• Celles qu’on essaie de faire passer par .bash_profile ou par .profile ne sont pas chargées.

• Celles qu’on passe par .bashrc ne fonctionnent que pour les applications lancées depuis un terminal.

• Celles qu’on passe par .config/environment.d/envvars.conf paraissent assez limitées dans leurs possibilités.

J’ai donc trouvé une solution presque satisfaisante avec la configuration suivante (à adapter à l’uid de chaque utilisateur) :

:::text
.bashrc
...
if [ -n "$DESKTOP_SESSION" ];then
    export GSM_SKIP_SSH_AGENT_WORKAROUND=1
    eval $(gnome-keyring-daemon --start)
    export SSH_AUTH_SOCK
fi

:::text
.config/environment.d/envvars.conf
...
SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"

Pour vérifier après redémarrage que les variables sont bien passées, on peut utiliser systemctl --user show-environment. J’ai pour ma part dû forcer les choses avec un systemctl --user import-environment, mais je ne saurais dire si c’est une étape nécessaire dans tous les cas ou non.

La solution n’est pas parfaite. Le déverrouillage de la clé SSH doit se faire initialement dans un terminal (ce qui est pour moi, de toute façon, l’usage très largement majoritaire). Mais ensuite, une application lancée graphiquement, comme Unison-gtk, peut utiliser les clés déverrouillées, ce qui n’est pas possible avec la seule modification de .bashrc. Jusque-là, je me contentais de lancer les applications graphiques depuis un terminal, ce qui est plus laborieux.

J’avoue que depuis que j’utilise i3 et Sway, je n’utilise presque plus Openbox et plus du tout Enlightenment. En effet, on gagne très largement en légèreté et en puissance, même si la courbe d’apprentissage est un peu plus raide. On renonce en partie à la métaphore du bureau popularisée par MacOS et par Windows, ce qui déroutera peut-être les débutants. En même temps, cette métaphore m’a toujours paru d’une facilité un peu trompeuse et maladroite : j’ai toujours l’impression de mimer des gestes avec une souris, un peu à la manière dont on communiquerait avec quelqu’un qui ne comprendrait pas votre langue. Dans le cas de Sway ou d’i3, on reste au maximum dans la conversation avec la machine grâce au clavier. Moins d’énergie perdue et plus d’efficacité.