XFCE's Wayland Compositor Has A Long Way To Go

SYNTHÈSE STRUCTURÉE

Contexte : la transition vers Wayland dans XFCE

L’intervenant explique que « presque tout le monde se dirige vers un futur Wayland », y compris XFCE. Il précise que ce mouvement est inévitable mais que « tant que quelqu’un travaille sur le code qui supporte X11, vous pouvez continuer à l’utiliser ». XFW4 est le résultat d’un travail mené principalement par Brian Harone, qui contribue à XFCE depuis 22 ans. Ce compositeur est basé sur Smithay, la même bibliothèque Rust utilisée par Cosmic et Niri, ce qui explique le choix du langage.

Difficultés de compilation et dépendances instables

Le compositeur XFW4 dépend de versions très récentes de bibliothèques XFCE (comme libxfce4ui, libxfce4windowing, xfce4-settings, xfce4-desktop) qui ne sont pas encore packagées dans les distributions mainstream. L’intervenant a testé Arch Linux et Majia, mais « c’est un peu pénible pour l’instant de le faire fonctionner ». Il recommande d’attendre une ISO de test ou un environnement packagé proprement, sauf si l’on souhaite contribuer au développement.

Utilisation pratique : un état très buggé mais fonctionnel

L’intervenant a réussi à lancer XFW4 sur une machine de test. Il montre que les applications de base (terminal, Thunar) fonctionnent, mais que de nombreux éléments sont cassés : le gestionnaire de fond d’écran plante aléatoirement, le panneau des espaces de travail n’affiche pas les vignettes, et les réglages de souris/touchpad ne s’ouvrent pas. Il résume : « C’est fonctionnel, c’est utilisable, ça progresse, mais c’est très, très buggé. »

Exécution en mode embarqué pour les tests

Une astuce pratique mentionnée : lancer XFW4 avec l’option xfw4 --help permet de le faire tourner comme client embarqué dans un autre bureau (Wayland ou X11). Cela évite les crashs qui feraient perdre tout le travail. L’intervenant conseille : « Si vous voulez aider au développement, c’est probablement une meilleure façon de le faire. »

Objectif : une transition transparente pour l’utilisateur

Le but affiché est que « les utilisateurs puissent passer de l’un à l’autre sans même savoir qu’il y a une différence ». L’intervenant compare à l’état actuel de KDE, où les réglages et le workflow sont largement conservés entre X11 et Wayland. Il admet que la réalité ne sera pas parfaite, mais que c’est « une première coupe solide ».

Problèmes connus et non implémentés

L’intervenant liste plusieurs fonctionnalités absentes ou cassées :

Le dialogue des réglages souris/touchpad ne s’ouvre pas du tout (protocole non implémenté).
Les réglages des espaces de travail (marges, nombre) ne fonctionnent pas.
Les raccourcis clavier pour la commutation d’applications (Alt+Tab) ne marchent pas.
La restauration des positions de fenêtres au démarrage n’est pas supportée (problème commun à tous les compositeurs Wayland, nécessitant le protocole XDG session management).

La question du langage Rust

Le développeur principal justifie le choix de Rust par « les raisons habituelles : pas de problèmes de sécurité mémoire, système de types fort, etc. » Il précise que seul le compositeur (XFW4) est réécrit en Rust, pas l’ensemble de XFCE. Les autres composants restent en C et fonctionnent sous X11 et Wayland. L’intervenant ajoute que « refactoriser XFWM4 pour en faire un compositeur Wayland n’était pas faisable » et qu’une réécriture séparée était moins risquée.

Pourquoi une réécriture plutôt qu’une adaptation de XFWM4

Le développeur a passé trois semaines à tenter d’adapter XFWM4, mais le code existant (basé sur la boucle principale GTK/Glib) est « fondamentalement incompatible avec la façon dont un serveur d’affichage Wayland doit être piloté ». Il a conclu qu’une réécriture propre était « l’option la moins risquée » et permettait de garder XFWM4 intact pour ceux qui veulent continuer à l’utiliser.

Calendrier réaliste : plusieurs années

L’intervenant estime qu’il faudra « probablement quelques années » pour que XFW4 atteigne un état où les utilisateurs de XFCE soient prêts à l’essayer, puis à l’utiliser quotidiennement. Il compare à l’état expérimental de Cinnamon sur Wayland. Il insiste sur le fait que c’est un problème de temps et de ressources, pas un problème fondamental avec Wayland.

Les protocoles Wayland déjà standardisés accélèrent le développement

L’intervenant souligne que la plupart des « discussions ennuyeuses et stupides » sur les protocoles Wayland (session restoration, positionnement des fenêtres, HDR) sont désormais réglées. XFCE n’a plus qu’à implémenter ces protocoles, ce qui réduit considérablement le temps de développement par rapport à ce qu’a connu KDE ou GNOME.

CONCEPTS CLÉS

Smithay : bibliothèque Rust pour écrire des compositeurs Wayland, utilisée par XFW4, Cosmic et Niri.
XDG session management protocol : protocole Wayland standardisé pour restaurer l’état des fenêtres (position, espace de travail) au démarrage.
WLR foreign toplevel management : protocole permettant aux barres de tâches et aux gestionnaires de fenêtres de connaître l’état des fenêtres (maximisé, minimisé, etc.).
Libxfce4windowing : nouvelle bibliothèque XFCE qui abstrait les différences entre X11 et Wayland pour les composants de l’environnement.

CONCLUSION

Le message principal est que XFW4 existe et fonctionne, mais qu’il est encore très loin d’être prêt pour une utilisation quotidienne. L’intervenant insiste sur le fait que les difficultés actuelles sont normales pour un projet aussi jeune, et que les fondations posées par les protocoles Wayland déjà standardisés devraient permettre à XFCE de rattraper son retard plus rapidement que d’autres environnements. Pour l’instant, il recommande de ne pas l’utiliser sauf pour contribuer au développement, et de continuer à utiliser XFWM4 sous X11.