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

[Gaël Bonithon]

Hi Brian,

------- Original Message -------
On Friday, September 23rd, 2022 at 8:13 PM, Brian Tarricone <brian at tarricone.org> wrote:

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

No problem, there is no reserved area ;) I just felt like I was in some kind of race, which I don't like. Sorry for my somewhat haphazard assumptions.

> 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.

Frankly, I don't feel ready to participate in discussions to influence the development of this or that protocol in one way or another. On the one hand I don't feel like it and on the other hand I think I have very little chance to succeed. My impression is that the GNOME law is largely in play here, but I could be wrong or exaggerate this aspect. I found this little article quite right for example: https://news.itsfoss.com/wayland-core-protocol-issue/

> 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?

Let's say that I prefer to see things as they happen and work on concrete things. I think that there are too many uncertainties about the features that we will actually be able to port to Wayland (as you yourself said above), to build right now an abstraction layer bridging X11 and Wayland. I prefer to port a certain functionality, using a certain protocol, test it with a compositor that exists, that is stable and that supports this protocol, and go on like that, step by step.

Even for Libxfcewl, while I was pretty sure from the start that something like this was going to be needed, I preferred to port the panel intellihide in Wayland code to start with. It allows to see on a real case what it looks like, before writing shared code. And it's not a problem at all to extract this code to put it in a library later.

So for the abstraction layer between Wayland and X11, I prefer to do the same at first. When porting the showdesktop panel plugin to Wayland, I left the wrappers switching between Wayland and X11 in the plugin code. They are just two small functions, I'm not sure I'll use them anywhere else for now, so why would I want to extract them right away? It can be done later if needed, when I have a better idea of what form it should take.

Regarding #ifdefs (which should rather be runtime checks, by the way), that's obviously a concern, but it can't always be avoided. Only simple cases will lend themselves to switch wrapping. In general, the code changes needed to make it work on Wayland will not necessarily have their X11 counterpart, so a unified API may not be possible, or may be an unwelcome constraint.

For example, I'm not sure it would be useful or suitable for porting the panel intellihide, even though for X11 as for Wayland it relies on information to be extracted from the active window. Having in the end a GdkScreen and an XfwlForeignToplevelManager to connect to doesn't seem to me to make the code unreadable or impossible to maintain. And if ever an abstraction layer should be useful or desirable, I prefer to see it emerge from real code, already tested a little and already proven its viability.

Finally, regarding where it should be put next, I suppose Libxfcewl could host it in a separate directory, optionally depending on Libwnck at compile time. Or it could be put in Libxfce4util. I'm not convinced at this point that a separate library for this is necessary, as it should only be wrappers switching between X11 and Wayland in my opinion (even if they were to take the form of interfaces, but is that necessary?).

But hey, all this is just my opinion, and it's not set in stone. I'm essentially discovering Wayland during this work, so we'll see :)

Cheers,
Gaël