Xfce Wiki

Sub domains

Xfce Wayland Development Roadmap

This document is intended for Xfce developers to keep track of Wayland development. This is a work in progress and does not imply any future implementation commitments.

Overall Plans

For Xfce 4.20, the plan is, to add preliminary support to Wayland to core components without losing X11 support. This doesn't mean that by the next major release an Xfce session on Wayland will offer all existing features, but we hope it will be minimally usable. We also intend to continue refining our applications to work acceptably on Wayland (those that already work or can be made to work with low effort).

Check the table in the component specific status section for details and labelled issues by group:

Long Term Goals

It is not clear yet which Xfce release will target a complete Xfce Wayland transition (or if such a transition will happen at all). Below is a list of larger tasks which would need to be done in some way for such a transition to occur.

Some of them are mostly agreed on by the Xfce devs.

Agreed guidelines

  • Do not depend on XWayland
    • No xsettings
  • Use wlroots over libmutter
    • keep the possibility to run xfdesktop and xfce4-panel as separate components
    • Prevent dependency on libgnome-desktop
    • xfce4-panel and xfdesktop have been ported to Wayland assuming our compositor will be based on wlroots.
    • There is also an unofficial port of xfwm4 in progress.
  • Keep X11 compatibility for the foreseeable future
    • Nvidia support to Wayland is still problematic, one more reason to keep X11 backward compatibility (nouveau driver usually is slower)
    • Wayland compositors which were written from scratch like Weston or sway will never run as a x11 window manager. But others which started as x11 window managers such as kwin or mutter still keep their x11 window management code
    • FreeBSD has decent support for Wayland, OpenBSD is still working on supporting Wayland

Component specific status

Core components

This table reflects the current status of what's released as 4.19 or git master.

Component Wayland Support Remarks
exo yes
libxfce4ui yes X11 code paths properly protected in libxfce4ui!110
libxfce4util yes
thunar yes
xfce4-appfinder yes
xfce4-panel yes See below
xfce4-session yes See xfce4-session!49 about limitations and how to use it
xfce4-settings yes See below
xfconf yes
xfdesktop yes See below
xfwm4 no
xfce4-power-manager yes See below
tumbler yes
garcon yes
thunar-volman yes
xfce4-dev-tools yes


  • Port to Wayland done: xfce4-panel!103
    • Wlroots-based, targeted compositors: Labwc, Wayfire
  • On Wayland the panel cannot use GtkSocket/GtkPlug any more to run plugins as external (separate processes). Initially, to advance in the porting of other features, it is enough to run them as internal (same process as the panel, so the crash of a plugin causes the panel to crash). If we want to get this back “natively” afterwards, it seems that we'll have to make the panel a Wayland compositor to some extent (Embedding Compositor, see also Allow embedding foreign wl_surfaces). For the moment the socket/plug structure has been reproduced on Wayland using the layer-shell protocol and D-Bus, which, although not native, has the merit of simplicity and of reusing what exists (more details here).


  • Port to Wayland done: xfdesktop!43
  • Workspaces support needs an X11/Wayland abstraction, and could use the wlr-workspace-unstable-v1 protocol on Wayland.
  • Listing all toplevel windows (windowlist menu, window icons on desktop) needs an X11/Wayland abstraction, and could use the wlr-foreign-toplevel-management-unstable-v1 protocol on Wayland.



  • A counterpart to xsettings on Wayland has been added in xfce4-settings!104, with the minimum of modifications to make xfsettingd executable on Wayland.
  • A port to Wayland of the display settings has been made in xfce4-settings!112, this time with a complete separation of the X11/Wayland code paths throughout xfce4-settings.
  • Of the things whose implementation is specific to X11, only the display settings are suitable for porting to Wayland. There is currently no protocol for the rest (keyboard, mouse, workspaces, etc., are all internal to the compositor).


  • Port to Wayland done: xfce4-power-manager!54
  • The essential features of user inactivity monitoring and display power management have been restored via protocols ext-idle-notify and wlr-output-power-management.
  • There's no real counterpart to brightness management (the wlr-gamma-control protocol offers similar functionality in appearance, but in fact has nothing to do with power saving), but the existing Polkit implementation works independently of the windowing environment.
  • Everything to do with keyboard handling (brightness keys, suspend key, etc.) is not restored, since only the compositor is currently able to manage this.


Component Wayland Support Remarks
xfce4-terminal yes drop-down requires layer-shell to work properly xfce4-terminal!72
mousepad yes
xfce4-notifyd yes
xfdashboard no crash on startup
xfce4-taskmanager yes no libwnck (appicons, xfce4-taskmanager#75), no “identify window”, no systray icon (xfce4-taskmanager#78)
xfce4-mixer yes
ristretto yes
catfish yes
xfburn yes
parole yes no systray icon (parole#126)
xfce4-screenshooter yes partial, see below
xfce4-screensaver no Port to Wayland is essentially done xfce4-screensaver!28
But this requires libwlembed, which is still experimental and has no release at this stage (2024-02-04)
xfmpc yes
xfce4-volumed-pulse no key bindings fail
xfce4-dict yes
gigolo yes
xfce4-panel-profiles yes


GTK doesn't appear to do anything special if you set a window to be override-redirect or always-on-top.


Wayland does not specify a native interface for the compositor for taking screenshots and it looks like it never will. We decided to use wlroots' screencopy protocol because that's probably what our compositor will support.

At the moment only Entire Screen screenshots are supported (xfce4-screenshooter!52), Rectangle Selection will be implemented next but Active Window is going to be much trickier, perhaps we'll need a custom protocol for our compositor to take care of that.

If we want to support compositors that don't implement the protocol above, we have to add DBus Support for org.freedesktop.portal.Screenshot. This however is not planned and it's unlikely we'll ever fully support other compositors.

Thunar Plugins

Component Wayland Support Remarks
thunar-archive-plugin yes
thunar-media-tags-plugin yes
thunar-shares-plugin yes
thunar-vcs-plugin yes

Panel Plugins

See details in the xfce4-panel section about how to run external plugins on Wayland. At first, “yes” below simply means “doesn't crash”, even after some elementary manipulations (eventually). It does not mean that everything works like on X11.

Component Wayland Support Remarks
xfce4-battery-plugin yes
xfce4-calculator-plugin yes insensitive text entry
xfce4-clipman-plugin yes Ported via wlr-data-control
TODO: use status notifier instead of status icon
xfce4-cpufreq-plugin yes
xfce4-cpugraph-plugin yes
xfce4-diskperf-plugin yes
xfce4-docklike-plugin yes Requires libxfce4windowing 4.19.3
xfce4-embed-plugin no unmaintained, gtk2
xfce4-eyes-plugin yes the pointer is not followed outside the panel
xfce4-fsguard-plugin yes
xfce4-generic-slider yes
xfce4-genmon-plugin yes
xfce4-indicator-plugin yes
xfce4-mailwatch-plugin yes
xfce4-mount-plugin yes
xfce4-mpc-plugin yes though probably relying on non working stuff (?)
xfce4-netload-plugin yes
xfce4-notes-plugin yes
xfce4-places-plugin yes icon issue, critical errors when removing the plugin
xfce4-pulseaudio-plugin yes with warnings (needs to be rechecked)
xfce4-sample-plugin yes
xfce4-sensors-plugin yes
xfce4-smartbookmark-plugin yes insensitive text entry
xfce4-stopwatch-plugin yes
xfce4-systemload-plugin yes
xfce4-time-out-plugin yes coredumps on pause and critical errors when removing/re-adding the plugin
xfce4-timer-plugin yes
xfce4-verve-plugin yes insensitive text entry
xfce4-wavelan-plugin yes
xfce4-weather-plugin yes
xfce4-whiskermenu-plugin yes icons issue, menu window floating
xfce4-windowck-plugin no does not work (Libwnck)
xfce4-xkb-plugin no crashes (Libwnck)


Info about testing specific components.

Regarding the version to test: master, or latest dev release would be best, though latest stable release as well will do. Currently there is not much difference for most components. If you don't test master, best add info on which version you tested.

If you run a NVidia GPU, you will need to use the “Nouveau” driver for testing, Since the proprietary NVidia driver does not provide Wayland support. (Though some things might work in some cases)

Native Wayland

  • Install Weston with your distribution package manager (if a Wlroots-based compositor is required, as for xfce4-panel, see this MR for more information)
  • Maybe set a minimal configuration, for example
  • Run weston in a terminal emulator, or better: in a tty with a different user, or by logging out of the X11 session first (the compositor may not have quite the same behavior, and this avoids interactions with the current environment)
  • If run in a terminal emulator, make sure at least the component to test isn't already running in your X11 session (e.g Thunar as daemon)
  • Open a terminal in the Weston session and start the component which is to be tested
  • For Wayfire you need to run startxfce4 --wayland from a tty (or the equivalent via a Display Manager), but before that add the following configuration:
    session = xfce4-session