xfdesktop & wayland

Brian Tarricone brian at tarricone.org
Mon Sep 19 23:04:54 CEST 2022


On Mon, Sep 19, 2022, at 10:28, andre at andreldm.com wrote:
> Regarding 4.18, I think we discussed it sometime ago that it would be another regular iteration of Xfce on X11, by the time of 4.20 cycle (in 2~4 years) we would have decided how bad is to continue using X11 and if a full migration would make sense. Of course nothing is set in stone.

Makes sense!

> Some core components such as Thunar and Appfinder are low hanging fruits, Wayland support can coexisting in their code base.

Right.  I feel like most of the apps will work with the gtk Wayland backend with few (or even no) changes.

> Others like Panel and Xfdesktop require a good deal of changes, I think you can decide which approach works best for you, either merge requests or forks in a "Wayland group". Please just keep the work somewhere visible in our gitlab instance and the wiki page[1] as updated as possible.

Sounds good.  My preference would be to have dual X11 & Wayland support in the same code base without requiring a fork.  With a fork, we essentially end up with separate programs that have to be maintained, and I don't think anyone has the bandwidth for that.

I'm especially concerned about the panel and lack of a Wayland analog for the XEMBED protocol.  It would be a shame if the X11 panel couldn't also support Wayland somehow, with the plugin process isolation that was added for a very good reason!  I do wonder if the XDG Foreign Protocol would help here, and allow out-of-process plugins to draw their UI in the right location.  Perhaps we'd need some sort of D-Bus interface to allow plugins and the panel to communicate with each other for the rest of their needs.

I see in another thread there's some talk about what to do with xfwm4 and a Wayland compositor.  It seems like the current route being taken is to start with a completely separate Wayland compositor to base the work on.  Personally my hope would be that xfwm4 itself could serve dual purposes.  Since even in the Wayland world you still need an X11 WM (for XWayland clients), it seems like it might be possible to share a lot of code between the X11-only WM and the XWayland WM.  Beyond that, the window management functions of the Wayland compositor should *really* reuse as much of xfwm4 as possible, as what makes a WM unique is the behavior around window handling.  Of course, a Wayland compositor is responsible for doing so much more than just window management... but perhaps that could be isolated in its own corner of the xfwm4 code.  Anyway, just some random thoughts.

     -brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20220919/814e7ec6/attachment.html>


More information about the Xfce4-dev mailing list