• Short Term Plans (Xfce 4.18)
• Long Term Goals(target release unknown)
  • Agreed
  • Topics under discussion
• Component specific status
  • Core components
  • Applications
    • xfce4-screenshooter
  • Thunar Plugins
  • Panel Plugins
• Testing
  • native wayland
  • xwayland
• Links

For Xfce 4.18, the plan is to ensure our applications are working acceptably on Wayland (those that already work or can be made to work with low effort). So, basically start testing with Weston and see if all menus, etc behave normally and ifdef Xlib code.

Check the table in the component specific section for details.

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, others are somewhat controversial (or no decision has been made so far).

• Do not depend on XWayland
  • No xsettings

• Use libmutter as a compositor library to show desktop and panels (similar to gnome-shell, but in plain C)
  • That most likely would require xfdesktop and xfce4-panel to be merged into a single component
  • The idea would be to not fork, but to just use libmutter
    • libmutter-7-0 seems to depend on libgnome-desktop-3-19 (debian bullseye). Can we drop that dependency somehow?
  • A big pro would be that ofourdan who is also a Gnome developer contributing to mutter
• Using wlroots instead would enable us to keep xfdesktop and xfce4-panel as separate components
  • Possibility to exchange only xfdesktop or xfce4-panel, but not the other.
  • Other implications? What would need to be done to use wlroots?
  • Downsides ?
• Which plugin system to use for panel plugin if GtkSocket/GtkPlug will not work any more?
• What about X11 backward compatibility?
  • As long as Nvidia does not support Wayland (by providing open drivers), it would be good 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
  • We do not have the resources to maintain our own Wayland compositor
  • FreeBSD provides https://hikari.acmelabs.space, not sure what is the situation for OpenBSD (possibly libinput missing?)
• ?

Back to Top

• On Wayland the panel cannot use GtkSocket/GtkPlug any more for plugins. Instead another approach would be to dlopen (e.g. through GModule) the plugins *.so and let the plugin just return a GtkWidget, which will be shown in the panel.

• Regarding tray icons, the panel already implements the freedesktop.org StatusNotifierItem specification. Though the plugins don't use those yet. Some plugins could be ported to do so. –> We would need some sample skeleton to start from to make it easier for contributors.

Wayland does not specify a native interface for the compositor for taking screenshots yet. Though there is a DBUS API offered by gnome(mutter?) for a desktop portal and as well wlroots has a screenshot protocol

So for xfce4-screenshooter there are the following options:

• Add DBus Support for org.freedesktop.portal.Screenshot (like that afaik screenshots should work with mutter)
• Add support for the wlroots screenshot protocol (link?)
• wait until wayland specifies a native interface (see here), and use it when available (Would make alot of sense for many applications, e.g. any video conferencing tool for screencast, so they dont need to implement multiple API's)

Note that backends for xdg-desktop-portals are as well in development for kde and wlroots:

• xdg-desktop-portal-kde
• xdg-desktop-portal-wlr

Currently (Feb 2020) both API's will give screenshots of the whole screen to any client. So far the user has not to approve a screenshot / give permission to specific applications (like e.g. on android). So the security is comparable to the X-Server.

Se as well: 1, 2

The panel's plugin system currently is based on GtkSocket/GtkPlug. This won't work on Wayland. Possible replacement could be GModule.

So before testing any panel-plugin on wayland, that problem needs to be resolved. See details in the xfce4-panel section.

Back to Top

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 dont 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)

In general, XWayland only is relevant if native Wayland does not work.

• Install Weston with your distribution package manager
• Run weston in a terminal emulator
• Make sure 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

• Install the package xwayland
• As above, but start weston with weston –backend=x11-backend.so –xwayland (to be confirmed if that is sufficient)

• Porting mate apps to wayland
• A deep dive into the wayland protocol
• Check if current display is a wayland display

Back to Top