Mon Sway réalisé
================
Date: 2019-03-23 10:01
Author: jdn06
Category: Logiciels libres
Tags: Sway, i3, Wayland, GNOME
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[1] 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) :
.bashrc
...
if [ -n "$DESKTOP_SESSION" ];then
export GSM_SKIP_SSH_AGENT_WORKAROUND=1
eval $(gnome-keyring-daemon --start)
export SSH_AUTH_SOCK
fi
.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é.
[1]
https://drewdevault.com/2019/01/23/Why-I-use-old-hardware.html
