First cut at a cross-"platform" X11/Wayland windowing library

[Brian Tarricone]

Hello Gaël,

On Fri, Sep 23, 2022, at 00:03, Gaël Bonithon wrote:

> You are of course perfectly free to write the code you want and create 
> a repository to share / show it, but discussions were already going on 
> here and on IRC (which you seem to follow) about the Libxfcewl library 
> (formerly named Libxfwl in my previous mails).
>
> I don't think we're going to create several Wayland related libraries 
> when the creation of only one is already hypothetical, so it would be 
> nice to consult each other before pushing a "competing" library, with a 
> different prefix for symbols by the way.

Sorry, I didn't mean to step on any toes!  I guess I got a little overly enthusiastic and excited about working on some of this stuff again, and didn't think to coordinate as well as I should have.  I did a lot of Xfce maintainership/work back in 2004-2009, but in 2009 I took a new job that meant I didn't have much time to work on open source projects.  That situation has finally changed, and I was excited about getting back into this stuff.  But that's no excuse; I'll make sure to coordinate and communicate better going forward!

The prefix I chose was more generic, as this isn't a Wayland specific library (I assume the "wl" in "libxfcewl" stands for "wayland"?); the "w" in "xfw" is just "windowing".  (Not completely happy with it, but... naming is hard!)

> Concerning the ext-workspace protocol project, I'm quite doubtful. It 
> is precisely only a project (since 2 years) and I think that no known 
> Wayland compositor (from which one can reasonably test something 
> concrete) implements it. So isn't it premature to write code around it?

The more I dive into this stuff, the more I'm wondering if it's premature to think about Wayland support for Xfce at all, unfortunately.  There are just _so_ many missing things in the Wayland ecosystem and protocol catalog.  I feel like a Wayland-ified Xfce today would be missing a lot of functionality that we all rely on.  I'm frankly surprised GNOME (for example) has been able to fully adopt Wayland.  I don't know what their architecture looks like, though, so perhaps they've gone the monolithic route and have built everything into the compositor process.  I guess maybe it isn't yet common to have several different independent components running that are allowed to have access to details a compositor might consider "internal".

Regarding the ext-workspace protocol in particular, I agree that it's disappointing that the original MR for it was submitted 2 years ago.  It does look like they're getting closer to merging (someone else has taken over for the original submitter), but there hasn't been any activity for a couple months now, and who knows, anyway.  But if that protocol (or something like it, but with hopefully minimal further changes) is going to end up being the way things are done, then I think looking into it now is a really good idea, especially if we can see what's lacking and possibly influence what eventually gets standardized.

Even the foreign toplevel protocol is severely lacking; you can't get the positions and sizes of toplevels (I have no idea how you'd implement a graphical pager, for instance), and seemingly-obvious window properties like the window icon (I assume Wayland, or at least one of the extension protocols, has provisions for window icons... I hope) are missing.

> Anyway, as a result of the discussions already started, I pushed a 
> repository for Libxfcewl: https://gitlab.xfce.org/Tamaranch/libxfcewl
> It passes make distcheck for me, I think it's relatively clean 
> (comparable to the existing code in the Xfce namespace anyway).

Looks good!  One concern I have about the general approach is that this looks like a Wayland-only library.  My thought was to create an abstraction that can support the required functionality on both X11 and Wayland, with the goal of avoiding a sea of #ifdefs in the Xfce component apps.  But it seems like a user of libxfcewl would have to have parallel, #ifdef'd code that uses libwnck (or whatever) in order to support both X11 and Wayland.  That seems less ideal from a maintenance and code readability perspective.  Is my understanding here incorrect?  Or were you considering building another abstraction library on top of libxfcewl & libwnck?

Cheers,
Brian