Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
releng:wayland_roadmap [2024/12/27 10:28] – [Applications] gaelreleng:wayland_roadmap [2026/01/30 10:13] (current) – [Overall Plans] fix xfwl4 FAQ link kelnos
Line 18: Line 18:
 ===== Overall Plans ===== ===== 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).+For Xfce 4.20, the plan was 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). 
 + 
 +For Xfce 4.22, the stabilization work continues. Reaching X11 feature parity is not yet our target. 
 + 
 +We are now working on our own [[https://gitlab.xfce.org/kelnos/xfwl4|Wayland compositor]].  It is very early, under heavy development, and not usable yet.  Please see [[/xfwl4_faq|its FAQ]] for further information.
  
 Check the table in the [[#component specific status]] section for details and labelled issues by group: Check the table in the [[#component specific status]] section for details and labelled issues by group:
Line 40: Line 44:
   * Do not depend on XWayland   * Do not depend on XWayland
     * No xsettings     * No xsettings
-  * Use wlroots over libmutter+  * Use smithay over wlroots and libmutter for our compositor
     * keep the possibility to run xfdesktop and xfce4-panel as separate components     * keep the possibility to run xfdesktop and xfce4-panel as separate components
     * Prevent dependency on libgnome-desktop     * Prevent dependency on libgnome-desktop
     * xfce4-panel and xfdesktop have been ported to Wayland assuming our compositor will be based on wlroots.     * xfce4-panel and xfdesktop have been ported to Wayland assuming our compositor will be based on wlroots.
-    * We plan to port xfwm4 to Wayland using wlroots but it will only be for Xfce 4.22 at best.+    * We plan to keep xfwm4 as X11-only, for Wayland a brand new compositor called xfwl4 was created.
   * Keep X11 compatibility for the foreseeable future   * 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)     * 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     * 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 [[https://docs.freebsd.org/en/books/handbook/wayland/|support]] for Wayland, OpenBSD is still [[https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayland-openbsd.pdf|working on supporting]] Wayland     * FreeBSD has decent [[https://docs.freebsd.org/en/books/handbook/wayland/|support]] for Wayland, OpenBSD is still [[https://www.openbsd.org/papers/eurobsdcon2023-matthieu-wayland-openbsd.pdf|working on supporting]] Wayland
 +    * We will archive this by having both a window manager (xfwm4/X11) and a compositor (xfwl4/wayland)
  
 ---- ----
Line 56: Line 61:
 === Core components === === Core components ===
  
-This table reflects the current status of what's released as 4.19 or git master.+This table reflects the current status of what's released as 4.21 or git master.
  
 ^ Component ^ Wayland Support ^ Remarks ^ ^ Component ^ Wayland Support ^ Remarks ^
Line 69: Line 74:
 | xfconf | yes | | | xfconf | yes | |
 | [[#xfdesktop]] | yes | See below | | [[#xfdesktop]] | yes | See below |
-| [[#xfwm4]] | no | |+| xfwm4 | not planned | xfwl4 will be its Wayland counterpart |
 | [[#xfce4-power-manager]] | yes | See below | | [[#xfce4-power-manager]] | yes | See below |
 | tumbler | yes | | | tumbler | yes | |
Line 87: Line 92:
   * Workspaces support needs an X11/Wayland abstraction, and could use the wlr-workspace-unstable-v1 protocol on Wayland.   * 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.   * 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.
- 
-=== xfwm4 === 
- 
-  * Unofficial port to Wayland in progress: https://github.com/adlocode/xfwm4/tree/wayland 
  
 === xfce4-settings === === xfce4-settings ===
Line 120: Line 121:
 | xfburn | yes | | | xfburn | yes | |
 | parole | yes | player window is not embedded ([[https://gitlab.xfce.org/apps/parole/-/issues/134|parole#134]]), no systray icon ([[https://gitlab.xfce.org/apps/parole/-/issues/126|parole#126]]) | | parole | yes | player window is not embedded ([[https://gitlab.xfce.org/apps/parole/-/issues/134|parole#134]]), no systray icon ([[https://gitlab.xfce.org/apps/parole/-/issues/126|parole#126]]) |
-| [[#xfce4-screenshooter]] | yes | partial, see below |+| [[#xfce4-screenshooter]] | yes | Active Window not supported |
 | xfce4-screensaver | no | Port to Wayland is essentially done [[https://gitlab.xfce.org/apps/xfce4-screensaver/-/merge_requests/28|xfce4-screensaver!28]] \\ But this requires [[https://gitlab.xfce.org/kelnos/libwlembed|libwlembed]], which is still experimental and has no release at this stage (2024-02-04) | | xfce4-screensaver | no | Port to Wayland is essentially done [[https://gitlab.xfce.org/apps/xfce4-screensaver/-/merge_requests/28|xfce4-screensaver!28]] \\ But this requires [[https://gitlab.xfce.org/kelnos/libwlembed|libwlembed]], which is still experimental and has no release at this stage (2024-02-04) |
 | xfmpc | yes | | | xfmpc | yes | |
Line 134: Line 135:
 === xfce4-screenshooter === === xfce4-screenshooter ===
  
-Wayland does not specify a native interface for the compositor for taking screenshots and it [[https://gitlab.freedesktop.org/wayland/wayland/-/issues/32|looks like]] it never will. We decided to use wlroots' [[https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/master/unstable/wlr-screencopy-unstable-v1.xml|screencopy protocol]] because that's probably what our compositor will support.+Entire Screen screenshot was initially [[https://gitlab.xfce.org/apps/xfce4-screenshooter/-/merge_requests/52|implemented]] using wlroots' [[https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/master/unstable/wlr-screencopy-unstable-v1.xml|screencopy protocol]]. Eventually support for ''ext-image-capture-source-v1'' and ''ext-image-copy-capture-v1'' was added. It's very likely that ''wlr-screencopy-unstable-v1'' (fallback) support will be dropped in the future.
  
-At the moment only Entire Screen screenshots are supported ([[https://gitlab.xfce.org/apps/xfce4-screenshooter/-/merge_requests/52|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.+Rectangle Selection was [[https://gitlab.xfce.org/apps/xfce4-screenshooter/-/merge_requests/80|implemented]] using gtk-layer-shell (''wlr_layer_shell_v1''). Active Window isn't possible with current protocols, 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 [[https://github.com/flatpak/xdg-desktop-portal|org.freedesktop.portal.Screenshot]]. This however is not planned and it's unlikely we'll ever fully support other compositors.+Compositors that don't implement the protocols mentioned above will not be supported.
  
 ---- ----
Line 217: Line 218:
   * [[https://frontpagelinux.com/articles/a-deep-dive-into-the-wayland-protocol-for-linux|A deep dive into the wayland protocol]]   * [[https://frontpagelinux.com/articles/a-deep-dive-into-the-wayland-protocol-for-linux|A deep dive into the wayland protocol]]
   * [[https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/57410e2dffde5271443809a0dbd0280be262ba47|Check if current display is a wayland display]]   * [[https://gitlab.xfce.org/xfce/libxfce4ui/-/commit/57410e2dffde5271443809a0dbd0280be262ba47|Check if current display is a wayland display]]
 +  * [[https://alexxcons.github.io/blogpost_15.html|Xfwl4 - The roadmap for a Xfce Wayland Compositor]]
  
 [[|Back to Top]] [[|Back to Top]]