Xfwl4 – Roadmap für den Wayland-Compositor von Xfce

 (alexxcons.github.io)
1 Punkte von GN⁺ 2026-01-29 | 1 Kommentare | Auf WhatsApp teilen
  • Das Xfce-Team hat Pläne für die Entwicklung des neuen Wayland-basierten Compositors „xfwl4“ vorgestellt; die Community-Spenden werden genutzt, damit der zentrale Entwickler Brian Tarricone die Arbeit leitet
  • Ziel sind dieselben Funktionen und dieselbe Benutzererfahrung wie bei xfwm4, wobei der Einstellungsdialog und die xfconf-Konfigurationen wiederverwendet werden, um einen nahtlosen Übergang zu sichern
  • Auf Basis von Rust und dem smithay-Framework als vollständig neuer Code geschrieben; bietet Speichersicherheit sowie anpassbare Grafik- und Eingabe-Pipelines
  • Zum Projektumfang gehören Änderungen an der Session-Management-Struktur, Unterstützung für XWayland und xdg-session-management sowie Verbesserungen am CI-Build-System
  • Eine zentrale Investition in den Wayland-Umstieg von Xfce; die erste Entwicklungsveröffentlichung ist noch im Laufe des Jahres geplant

Xfces neuer Plan für einen Wayland-Compositor

  • Das Xfce-Team beginnt mit der Entwicklung des neuen Wayland-Compositors „xfwl4“ unter Nutzung von Community-Spenden
    • Die Entwicklung übernimmt der langjährige Kernbeitragende Brian Tarricone
    • Ein erheblicher Teil der Projektmittel soll für diese Entwicklung verwendet werden
  • Ziel ist es, dieselben Funktionen und dasselbe Verhalten wie xfwm4 in einer Wayland-Umgebung bereitzustellen
    • Die bestehenden xfwm4-Einstellungsdialoge und xfconf-Einstellungen werden unverändert genutzt, um eine konsistente Benutzererfahrung zu wahren
  • xfwl4 basiert nicht auf dem bestehenden xfwm4-Code, sondern wird in Rust vollständig neu geschrieben
    • Es wird auf der smithay-Bibliothek aufgebaut

Warum eine Neuentwicklung statt Wiederverwendung des bestehenden Codes

  • Anfangs war geplant, den xfwm4-Code anzupassen, um X11 und Wayland parallel zu unterstützen, doch aus mehreren Gründen wurde dies als ungeeignet bewertet
    • Die Struktur von xfwm4 ist stark von X11 abhängig, wodurch sich eine verallgemeinerte Schnittstelle nur schwer umsetzen lässt
    • Bei einem Refactoring besteht ein hohes Risiko für X11-Bugs
    • Es gibt X11-Konzepte, die unter Wayland nicht unterstützt werden, was die Pflege des Codes erschwert
    • Bei Nutzung des bestehenden Codes wäre man auf C und wlroots angewiesen
  • Mit einer separaten Codebasis lassen sich die Stabilität von xfwm4 erhalten und experimentelle Wayland-Entwicklung parallel vorantreiben

Warum smithay gewählt wurde

  • Brian Tarricone verglich wlroots und smithay und entschied sich anschließend für smithay
    • smithay unterstützt die meisten offiziellen Wayland-Protokollerweiterungen sowie wlroots- und KDE-Protokolle
    • Durch das Fehlen einer High-Level-Abstraktion ist eine feingranulare Kontrolle über Grafik- und Eingabe-Pipelines möglich
    • Die Dokumentation ist gut, und durch Rust sinkt das Risiko speicherbezogener Bugs und Abstürze
    • Der Entwickler bevorzugt Rust
    • wlroots ist in C geschrieben, wodurch sich Rust-Bindings nur schwer erstellen lassen

Projektumfang und technische Herausforderungen

  • Zusätzlich zur Funktionsgleichheit mit xfwm4 umfasst das Projekt folgende Aufgaben
    • In einer Wayland-Umgebung muss der Compositor die Session-Wurzel sein, daher ist eine Änderung der Session-Startstruktur erforderlich
    • Unterstützung für das xdg-session-management-Protokoll wird ergänzt
    • XWayland-Unterstützung ist enthalten
    • Das CI-Container-Build-System wird auf eine meson-basierte Struktur aktualisiert, die den Build von Rust-Code ermöglicht
  • Brian Tarricone hat die Entwicklung bereits begonnen; die erste Entwicklungsveröffentlichung ist noch im Laufe des Jahres geplant

Community und Förderung

  • Das Projekt wird durch Spenden von Unterstützern von Open Collective US und EU ermöglicht
  • Entwicklungsfortschritt und technische Details können in den xfwl4-Issues und dem Quellcode-Repository auf GitLab verfolgt werden
  • Fragen dazu können über den Matrix-Kanal #xfce-dev gestellt werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-29
Hacker-News-Kommentare

  • Ich habe gehört, dass xfwl4 auf dieselben Funktionen und dasselbe Verhalten wie xfwm4 abzielt.
    Wenn man jedoch die strukturellen Unterschiede zwischen X11 und Wayland berücksichtigt, frage ich mich, wie streng „Verhalten“ hier ausgelegt wird.
    Zum Beispiel erfordert Schutz vor Fokusdiebstahl unter X11 komplizierte Heuristiken und Timestamp-Prüfungen, während unter Wayland der Compositor den Fokus vollständig kontrolliert.
    Letztlich besteht also die Aufgabe darin, neue Richtlinien zu entwerfen, die das Gefühl der alten Heuristiken bewahren und zugleich zum Berechtigungsmodell von Wayland passen.
    Ein weiterer interessanter Punkt ist die durch erzwungenes Compositing verursachte Latenz. Ich frage mich, ob auf leistungsschwacher Hardware eine ähnliche Reaktionsfähigkeit wie im nicht-komponierten Modus von X11 erreichbar ist.

    • Ich bin xfwl4-Entwickler. Es ist genau so gemeint, wie „so ähnlich wie möglich“ sagt. Es wird nicht völlig identisch sein, aber wir wollen so nah wie möglich herankommen.
      Der Schutz vor Fokusdiebstahl könnte unter Wayland sogar konsistenteres Verhalten zeigen. Xfwm4 basierte auf Heuristiken und lag gelegentlich daneben, aber das xdg-activation-Modell von Wayland ist deutlich klarer.
      Bei der Performance dürfte es auf moderner Hardware keinen großen Unterschied geben, aber bei sehr alten Geräten könnte es belastend sein. Das lässt sich realistisch wohl erst mit mehr Tests sagen.
    • Ich habe früher den xfwm-Compositor auf einem 400MHz-Pentium II mit GeForce 2 betrieben, und das lief problemlos.
      Die Last durch Compositing ist praktisch nur die Wartezeit auf vsync. Solange es kein Pentium Classic ist, sollte es passen.
    • Mir gefällt, dass die Gründe offen genannt werden. Die Einführung von Rust als eine Art Sprachinsel kann zwar bei Build-Tooling oder der Integration ins Ökosystem Reibung verursachen, aber trotzdem war ich mit XFCE immer viel zufriedener als mit GNOME.
    • Compositing muss nicht zwingend mit vsync gekoppelt sein. Der Bildschirm kann auch sofort aktualisiert werden, wenn der Client neue Inhalte sendet.
    • Heutzutage ist der Overhead eines Compositors selbst auf günstigen Intel-GPUs kaum noch ein Problem. Eine Ausnahme sind höchstens Leute mit 20 Jahre alten Laptops.

  • Ich hoffe, dass XFCE weiterhin ein leichtgewichtiges Desktop-Environment bleibt.
    Ich mag KDE, aber als leichtgewichtig würde ich es nicht bezeichnen.
    Wayland und Rust sehe ich beide positiv; Wayland ist die Richtung der Zukunft, und Rust hilft meiner Meinung nach bei der Vermeidung von Abstürzen.
    Allerdings ist die traditionelle XFCE-Nutzerschaft eher konservativ und könnte neuen Technologien skeptisch gegenüberstehen.

    • Als jemand, der XFCE seit 2007 nutzt, kann ich sagen: Den Nutzern geht es weniger um Sprache oder Technik als darum, dass es einfach gut funktioniert.
      Der Wechsel zu Wayland ist unvermeidlich, und es wird zwar etwas Gemecker geben, aber insgesamt dürfte er ohne größere Probleme verlaufen.
      Die Gruppe der X11-Hardliner wird am Ende nur eine Minderheit sein. Ich vertraue dem XFCE-Team.
    • Ich verstehe nicht, warum Wayland sich „wie die Zukunft“ anfühlen soll. Für mich wirkt es eher wie funktionaler Rückschritt.
      Es gibt bereits ein GUI, das gut funktioniert, und Wayland schafft unnötige Komplexität und Kompatibilitätsprobleme.
      Einfache Protokolle überleben normalerweise länger, und Wayland ist eher das Gegenteil.
    • Ich vertrete die Haltung: „Was nicht repariert werden muss, sollte man nicht reparieren.“
      XFCE ist bereits schnell und stabil. Wenn es durch den Wechsel zu Wayland langsamer wird, verliert es damit seinen größten Vorteil.
    • Ich denke, der Umstieg von XFCE auf Wayland wird Zeit brauchen.
      Da die Community auf Stabilität setzt, wird man X11 wohl zunächst als Standard beibehalten und erst dann auf Wayland wechseln, wenn vollständige Funktionsgleichheit erreicht ist.
    • Als langjähriger XFCE-Nutzer sehe ich diese Veränderung positiv, solange X11 nicht übereilt aufgegeben wird.
      Ich hoffe, dass ich XFCE weiter nutzen kann, wenn ich irgendwann zu Wayland wechseln muss.

  • Ich denke, dieses Projekt selbst zeigt, dass Wayland die richtige Richtung ist.
    Xorg war eine einzelne Implementierung, aber rund um Wayland ist ein vielfältiges Bibliotheks-Ökosystem entstanden (wlroots, Smithay usw.).
    Dadurch kann selbst ein Ein-Personen-Projekt in wenigen Monaten eine Developer Preview veröffentlichen.
    Diese Art von Wettbewerb wird das Open-Source-Ökosystem voranbringen.

    • Da Wayland nur Low-Level-Funktionalität bereitstellt, musste man hastig gemeinsame Desktop-Schnittstellen schaffen.
      Dieser Prozess lief jedoch zu überstürzt ab, weshalb es an Integration fehlt. Bis sich eine vollständige Linux-Desktop-API etabliert, werden meiner Ansicht nach noch zehn Jahre vergehen.
    • Mehrere Implementierungen schaffen zwar Wettbewerb, können aber wegen Mangel an Maintainer-Kapazität auch zu fehlenden Funktionen und Burnout führen.
      Das Fehlen von libcompositor halte ich für den größten Fehler von Wayland.
    • Der Code wird zwar redundanter, aber dafür kann jedes Team eine Implementierung nach seiner eigenen Philosophie bauen.
      Ich bin gespannt, was das XFCE-Team daraus macht.
    • Diese Logik erinnert mich an die Zeit, als Rails übermäßig eingesetzt wurde.
      So ein Stack ist zwar bequem, kann aber am Ende zu einer Struktur führen, die sich nur schwer tiefgreifend anpassen lässt.
    • Der Kern von Wayland ist, dass der Kernel viele Aufgaben übernimmt.
      X funktionierte faktisch wie ein zweiter Kernel, während Wayland moderne Abstraktionen des Kernels wie GEM, DMA-BUF und KMS nutzt.
      Dadurch kann sich die Architektur deutlich sauberer und effizienter weiterentwickeln.

  • Ich nutze XFCE seit mehr als zehn Jahren als Hauptumgebung.
    Die Nachricht über Wayland-Unterstützung freut mich.
    Wenn es in Rust geschrieben wird, könnte das auch helfen, mehr Mitwirkende anzuziehen.
    Wenn ihr unterstützen möchtet, empfehle ich Spenden an Open Collective und xfce-eu.

    • Ich nutze XFCE seit fünf Jahren und habe vor Kurzem begonnen, monatlich zu spenden. Das sind tolle Neuigkeiten, ich freue mich darüber.

  • Ich denke, der Übergang von X11 zu Wayland ist die schmerzhafteste Veränderung in der Geschichte von Linux.

    • Der Wechsel vom Kernel 2.4 zu 2.6 war ebenfalls ziemlich hart. Das Entwicklungsmodell änderte sich vollständig, und die Zeit vor Git war chaotisch.
      Auch die KDE4-Ära war eine dunkle Zeit.
    • Für mich persönlich war der Wechsel von GNOME 2 zu GNOME 3 am schlimmsten. Ich bin am Ende zu einem anderen WM gewechselt.
    • Für mich verlief der Übergang von X11 zu Wayland sehr reibungslos. Es hängt letztlich von den jeweiligen Anforderungen ab.
    • In acht Jahren ist Wayland vielleicht genauso alt wie X11 jetzt, und dann bekommen wir womöglich Wayland 2.
    • Auch der Wechsel zu systemd war nicht ohne.

  • Ich habe das Rust-Client-Toolkit von Smithay ausprobiert, aber die Thread-Sicherheit ist nicht vollständig.
    Selbst wenn alles in Arc<> verpackt ist, treten bei Multithread-Aufrufen seltsame Abstürze auf.
    Ich würde gern lernen, wie man sich direkt in die Wayland-API einarbeitet und sie sicher verwendet.

  • Schon jetzt kann man XFCE auf den meisten wlroots-basierten Compositors verwenden.
    Ich nutze auf Gentoo eine Kombination aus Hyprland + XFCE.
    Die Konfiguration gibt es in diesem Repository.

    • Mir gefällt das Retro-Theme.
      Ich frage mich, warum die Kombination aus Hyprland und XFCE4 als „verfluchte Kombination“ bezeichnet wurde. Vermutlich hängt das mit dem Grund zusammen, warum XFCE beschlossen hat, einen eigenen Compositor zu bauen.

  • Früher habe ich Wayland abgelehnt, aber wegen der Performance auf alter Hardware meine Meinung geändert.
    Auf einem alten ThinkPad scrollt Firefox deutlich flüssiger als unter X11.
    Auch die zusätzlichen Touchpad-Gesten gefallen mir. Die Einrichtung ist zwar etwas mühsam, aber ein lohnender Trade-off.

  • Ich frage mich, ob Wayland auch auf Nicht-Linux-Systemen läuft. Kann man zum Beispiel unter BSD oder macOS wie mit XQuartz entfernte Fenster anzeigen?

    • Unter FreeBSD funktioniert es ziemlich gut. Auch unter OpenBSD laufen einige wlroots-basierte Compositors teilweise.
      Es gibt auch Wayland-Compositors für den Mac, und Brodie Robertson hat dazu ein Video veröffentlicht.
    • Microsofts WSL2-GUI-Integration basiert ebenfalls auf Wayland und XWayland.
      Im WSLg-Projekt sieht man, dass Weston per RDP gerendert wird, sodass Fenster plattformübergreifend angezeigt werden können.
      GPU-Beschleunigung bleibt dabei erhalten, was ich besser finde als X11-Forwarding.
    • Wayland hat keine Netzwerktransparenz, daher ist Remote-Übertragung komplizierter. Der Stand auf dem Mac ist unklar.
    • Im offiziellen FreeBSD-Handbuch gibt es ebenfalls eine Anleitung zur Wayland-Einrichtung.
      FreeBSD Handbook Wayland
    • Auch unter OpenBSD wird mit dem Dokument Wayland_on_OpenBSD experimentiert.

  • Heutzutage klingt „Rewrite in Rust“ für mich oft so, als ob die Maintainer fehlen.
    Es wirkt, als gäbe es niemanden mehr, der xfwm4 patchen will, also schreibt man es neu.
    Das könnte ein Zeichen für einen Generationenwechsel sein — neue Entwickler wollen alles in einer einfachen und sicheren Struktur neu aufbauen.
    Wayland ist einfacher als X11, und Rust reduziert Fehler, daher ist das ein natürlicher Verlauf.
    Aber der Preis dafür könnte sein, dass Netzwerktransparenz, Performance und Stabilität leiden. Ich akzeptiere es als Zeichen der Zeit.