Xfwl4 – feuille de route du compositeur Wayland pour Xfce

 (alexxcons.github.io)
1 points par GN⁺ 2026-01-29 | 1 commentaires | Partager sur WhatsApp
  • L’équipe Xfce a dévoilé son projet de développer un nouveau compositeur basé sur Wayland, « xfwl4 », sous la direction du développeur clé Brian Tarricone grâce aux dons de la communauté
  • L’objectif est d’offrir les mêmes fonctionnalités et la même expérience utilisateur que xfwm4, en réutilisant la boîte de dialogue de configuration et la configuration xfconf afin d’assurer une transition continue
  • Écrit entièrement comme une nouvelle base de code sur Rust et le framework smithay, il offre une meilleure sûreté mémoire ainsi qu’un pipeline graphique et d’entrée personnalisable
  • Le périmètre du projet inclut des changements dans l’architecture de gestion de session, la prise en charge de XWayland et de xdg-session-management, ainsi que l’amélioration du système de build CI
  • Il s’agit d’un investissement clé pour la transition de Xfce vers Wayland, avec une première release de développement prévue dans l’année

Le nouveau projet de compositeur Wayland de Xfce

  • L’équipe Xfce a lancé le développement de son nouveau compositeur Wayland « xfwl4 » grâce aux dons de la communauté
    • Le développement est assuré par Brian Tarricone, contributeur central de longue date
    • Une part importante des fonds du projet sera consacrée à ce développement
  • L’objectif est de reproduire les mêmes fonctionnalités et le même comportement que xfwm4 dans un environnement Wayland
    • La boîte de dialogue de configuration de xfwm4 et les réglages xfconf seront réutilisés tels quels pour préserver la cohérence de l’expérience utilisateur
  • xfwl4 ne repose pas sur le code existant de xfwm4 et sera entièrement réécrit en Rust
    • Il sera construit sur la bibliothèque smithay
    Publicité

Pourquoi choisir une réécriture plutôt que la réutilisation du code existant

  • Au départ, l’idée était de modifier le code de xfwm4 pour prendre en charge à la fois X11 et Wayland, mais cette approche a finalement été jugée inadaptée pour plusieurs raisons
    • L’architecture de xfwm4 est fortement dépendante de X11, ce qui rend difficile l’implémentation d’interfaces généralisées
    • Un refactoring ferait peser un risque élevé d’introduire des bugs côté X11
    • Il existe des concepts X11 non pris en charge par Wayland, ce qui compliquerait la maintenance du code
    • Réutiliser le code existant obligerait à dépendre du langage C et de wlroots
  • Développer une base de code séparée permet de préserver la stabilité de xfwm4 tout en menant en parallèle un développement expérimental pour Wayland

Pourquoi smithay a été choisi

  • Brian Tarricone a évalué wlroots et smithay avant de retenir smithay
    • smithay prend en charge la plupart des extensions officielles du protocole Wayland ainsi que les protocoles wlroots et KDE
    • L’absence d’abstractions de haut niveau permet un contrôle fin du pipeline graphique et d’entrée
    • La documentation est de grande qualité et l’usage de Rust réduit les risques de bugs mémoire et de crashs
    • Le développeur préfère Rust
    • wlroots étant écrit en C, écrire des bindings Rust y est difficile
    Publicité

Périmètre du projet et défis techniques

  • En plus de l’alignement fonctionnel avec xfwm4, le projet inclut les points suivants
    • Dans un environnement Wayland, le compositeur doit devenir la racine de la session, ce qui nécessite de modifier l’architecture de démarrage de session
    • Ajout de la prise en charge du protocole xdg-session-management
    • Intégration de XWayland
    • Mise à niveau du système de build de conteneurs CI vers une base meson capable de compiler du code Rust
  • Brian Tarricone a déjà commencé le développement, et une première release de développement est prévue dans l’année

Communauté et soutien

  • Le projet a été rendu possible grâce aux dons des soutiens Open Collective US et EU
  • L’avancement du développement et les détails techniques sont consultables via les tickets xfwl4 sur GitLab et le dépôt du code source
  • Les questions liées au projet peuvent être adressées via le canal Matrix #xfce-dev

À lire aussi

1 commentaires

 
GN⁺ 2026-01-29
Avis sur Hacker News

  • J’ai entendu dire que xfwl4 vise les mêmes fonctionnalités et le même comportement que xfwm4
    Mais vu les différences structurelles entre X11 et Wayland, je me demande à quel point l’interprétation de « comportement » sera stricte
    Par exemple, la prévention du vol de focus demande sous X11 des heuristiques complexes et des vérifications de timestamps, alors que sous Wayland, le compositeur contrôle entièrement le focus
    Au final, il faut concevoir de nouvelles politiques compatibles avec le modèle d’autorité de Wayland, tout en conservant le ressenti des anciennes heuristiques
    Un autre point d’intérêt est la latence induite par le compositing forcé. Je me demande si, sur du matériel modeste, on pourra atteindre une réactivité comparable au mode non composité de X11

    • Je suis le développeur de xfwl4. Cela signifie exactement « aussi similaire que possible ». Ce ne sera pas totalement identique, mais on essaiera de s’en approcher au maximum
      La prévention du vol de focus pourrait même avoir un comportement plus cohérent côté Wayland. Xfwm4 reposait sur des heuristiques et se trompait parfois, tandis que le modèle xdg-activation de Wayland est bien plus clair
      Côté performances, je pense qu’il n’y aura pas de grande différence sur du matériel récent, mais que cela pourrait peser sur des machines très anciennes. En pratique, il faudra davantage de tests pour le savoir
    • J’avais fait tourner le compositeur de xfwm sur un Pentium II à 400 MHz avec une GeForce 2, et ça passait sans problème
      Le coût du compositing, en pratique, c’est surtout le temps d’attente de la vsync. À moins d’être sur un processeur de la classe Pentium classique, ça devrait aller
    • J’apprécie qu’ils exposent honnêtement leurs raisons. L’adoption de Rust comme îlot linguistique peut créer des frictions dans l’outillage de build ou l’intégration à l’écosystème, mais malgré ça, XFCE m’a toujours bien plus satisfait que GNOME
    • Le compositing n’a pas forcément besoin d’aller de pair avec la vsync. On peut aussi rafraîchir l’écran immédiatement quand le client envoie du nouveau contenu
    • De nos jours, même sur des GPU Intel d’entrée de gamme, la surcharge d’un compositeur n’est quasiment plus un problème. À part pour ceux qui utilisent encore des portables vieux de 20 ans

  • J’espère que XFCE restera un bureau léger
    J’aime KDE, mais il est difficile de le qualifier de léger
    Je vois d’un bon œil à la fois Wayland et Rust : Wayland est la direction à prendre, et Rust aide à éviter les plantages
    En revanche, la base d’utilisateurs traditionnelle de XFCE est plutôt conservatrice, donc elle peut se montrer sceptique face aux nouvelles technologies

    • En tant qu’utilisateur de XFCE depuis 2007, je dirais que les gens veulent avant tout « que ça marche » plutôt qu’un langage ou une technologie en particulier
      La transition vers Wayland est inévitable, il y aura bien quelques plaintes, mais elle se fera sans gros problème
      Les irréductibles de X11 finiront par rester minoritaires. J’ai confiance dans l’équipe XFCE
    • Je ne vois pas pourquoi Wayland est censé « ressembler à l’avenir ». J’ai plutôt l’impression d’une régression fonctionnelle
      On avait déjà une GUI qui fonctionnait bien, et Wayland apporte une complexité inutile ainsi que des problèmes de compatibilité
      Ce sont les protocoles simples qui durent, et Wayland va dans le sens inverse
    • Je suis plutôt du genre « ne répare pas ce qui n’est pas cassé »
      XFCE est déjà rapide et stable. Si le passage à Wayland le ralentit, il perdra alors son principal atout
    • Je pense que la transition de XFCE vers Wayland prendra du temps
      C’est une communauté qui privilégie la stabilité, donc X11 restera probablement le choix par défaut jusqu’à obtenir une parité fonctionnelle complète avant de basculer sur Wayland
    • En tant qu’ancien utilisateur de XFCE, je vois ce changement positivement tant qu’on ne supprime pas X11 dans la précipitation
      J’espère pouvoir continuer à utiliser XFCE le jour où il faudra vraiment passer à Wayland

  • Je pense que ce projet montre en lui-même que Wayland va dans la bonne direction
    Xorg était une implémentation unique, alors que Wayland a fait émerger tout un écosystème de bibliothèques (wlroots, Smithay, etc.)
    Grâce à cela, même un projet porté par une seule personne peut sortir une preview développeur en quelques mois
    Cette concurrence fera progresser l’écosystème open source

    • Comme Wayland ne fournit que des fonctions bas niveau, il a fallu construire à la hâte des interfaces de bureau communes
      Mais ce processus a été mené trop vite et manque d’intégration. À mon avis, il faudra encore 10 ans avant qu’une API de bureau Linux vraiment complète s’impose
    • Quand plusieurs implémentations apparaissent, il y a de la concurrence, mais cela peut aussi entraîner des fonctionnalités manquantes et du burn-out à cause du manque de mainteneurs
      Je pense que l’absence d’une libcompositor est la plus grosse erreur de Wayland
    • Il y aura forcément plus de duplication de code, mais chaque équipe pourra ainsi produire une implémentation conforme à sa philosophie
      J’ai hâte de voir ce que l’équipe XFCE va proposer
    • Cette logique me rappelle l’époque où Rails était utilisé à toutes les sauces
      La pile est pratique, mais elle peut finir par former une structure difficile à modifier en profondeur
    • Le cœur de Wayland, c’est que le noyau prend désormais en charge une grande partie du travail
      X se comportait en pratique comme un second noyau, tandis que Wayland s’appuie sur des abstractions modernes du noyau comme GEM, DMA-BUF ou KMS
      Cela permet d’évoluer vers une architecture bien plus propre et efficace

  • J’utilise XFCE comme environnement principal depuis plus de 10 ans
    Je suis ravi d’apprendre l’arrivée du support Wayland
    Le fait qu’il soit écrit en Rust pourrait aussi aider à attirer de nouveaux contributeurs
    Si vous voulez soutenir le projet, je recommande de faire un don à Open Collective et à xfce-eu

    • J’utilise XFCE depuis 5 ans et j’ai commencé à faire un don mensuel récemment. Excellente nouvelle, ça me fait plaisir

  • Je pense que le passage de X11 à Wayland est le changement le plus douloureux de l’histoire de Linux

    • Le passage du noyau 2.4 au 2.6 avait déjà été assez rude. Le modèle de développement avait complètement changé, et l’époque d’avant git était chaotique
      L’ère KDE4 a aussi été une période sombre
    • Personnellement, c’est la transition GNOME 2 → GNOME 3 qui a été la plus pénible. J’ai fini par passer à un autre WM
    • Pour moi, la transition de X11 à Wayland s’est faite très en douceur. Au final, tout dépend des besoins
    • Dans 8 ans, Wayland sera peut-être lui aussi aussi ancien que X11, et on verra peut-être arriver Wayland 2
    • La transition vers systemd n’a pas été simple non plus

  • J’ai essayé le toolkit client Rust de Smithay, mais sa sécurité des threads ne semble pas complète
    Même enveloppé dans Arc<>, j’obtiens d’étranges plantages lors d’appels multithread
    J’aimerais apprendre à manipuler directement l’API Wayland pour l’utiliser proprement et en toute sécurité

  • On peut déjà utiliser XFCE avec la plupart des compositeurs basés sur wlroots
    De mon côté, j’utilise la combinaison Hyprland + XFCE sur Gentoo
    La configuration est dans ce dépôt

    • J’aime bien le thème rétro
      Je me demande pourquoi tu qualifies la combinaison Hyprland et XFCE4 de « combinaison maudite ». C’est peut-être lié à la raison pour laquelle XFCE a décidé de créer son propre compositeur

  • J’étais autrefois opposé à Wayland, mais j’ai changé d’avis en voyant les performances sur du vieux matériel
    Sur un vieux ThinkPad, Firefox défile bien plus fluidement que sous X11
    Les gestes du touchpad sont aussi un vrai plus. La configuration est un peu fastidieuse, mais c’est un compromis qui en vaut la peine

  • Je me demande si Wayland fonctionne aussi sur des systèmes non Linux. Par exemple, peut-on afficher des fenêtres distantes sur BSD ou macOS comme avec XQuartz ?

    • Sur FreeBSD, ça fonctionne plutôt bien. Sur OpenBSD aussi, certains compositeurs basés sur wlroots tournent partiellement
      Il existe également des compositeurs Wayland pour Mac, et Brodie Robertson a publié une vidéo à ce sujet
    • L’intégration GUI de WSL2 chez Microsoft repose elle aussi sur Wayland et XWayland
      En regardant le projet WSLg, on voit que Weston est rendu via RDP, ce qui permet d’afficher des fenêtres entre plateformes
      L’accélération GPU est également conservée, ce qui est à mon avis préférable au simple forwarding X11
    • Wayland n’est pas transparent au réseau, donc le transport à distance est plus complexe. L’état de la situation sur Mac reste incertain
    • Le handbook officiel de FreeBSD explique aussi comment configurer Wayland
      FreeBSD Handbook Wayland
    • Sur OpenBSD, des expérimentations sont également documentées dans Wayland_on_OpenBSD

  • Aujourd’hui, quand j’entends parler de « réécriture en Rust », j’ai surtout l’impression qu’il n’y a plus assez de mainteneurs
    On dirait qu’il n’y a plus personne pour patcher xfwm4, donc ils repartent de zéro
    Cela peut aussi être le signe d’un renouvellement générationnel : de nouveaux développeurs veulent reconstruire avec une architecture simple et sûre
    Wayland est plus simple que X11, et Rust réduit les erreurs, donc l’évolution semble naturelle
    Mais le prix à payer pourrait être la perte de transparence réseau, de performances et de stabilité. J’accepte que ce soit le sens de l’époque