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

[Brian Tarricone]

On Sat, Sep 24, 2022, at 01:43, Gaël Bonithon wrote:

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

Thanks for being so gracious about it!  And no worries, I know if some random person I'd never met before started jumping in and doing some work in an area I was working in, I'd feel a bit bad about the situation too.

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

Ugh, that's... not fun.  I found a couple more things to read as well, through the link you provided, and it sounds pretty bad.  Not really surprised, though, as the GNOME folks have been behaving like this for many years in other ways (like GTK4 being GNOME-centric and dropping features that GNOME doesn't need but other people might need to use).  GNOME cares about GNOME, and that's all.

The bit that gives me hope, though, is that it essentially looks like GNOME vs. _literally everyone else_.  They might be gatekeepers of the wayland-server, wayland-client, and wayland-protocols repositories right now, but I feel like that might change in the longer term, especially as GNOME-on-Wayland is more "done" and things are more settled.  In some ways I can understand not caring about other environments when you have a lot of work to do for your own, and deadlines for when it needs to be done, even if it feels like an anti-social, anti-community attitude.  The community that supports wlroots (essentially everyone but GNOME and Enlightenment!) seems really strong, and it might even be pleasant and fun to work with them on standardizing things outside of the "official" Wayland umbrella.  Agree that working with the core Wayland people probably wouldn't be fun, especially if things like the 2-years-and-counting ext-workspace protocol MR are typical.

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

Makes sense!  I think I do work that way sometimes, but often I'll also think ahead to where I think I want to be eventually.  I think of this as the tension between building something more prototype-y to get things working quickly, and then evolving it over time toward the final state, vs. taking more time up-front to target the final state with fewer iterations.  The latter path tends to make it take longer before you see anything usefully working, but I know I get frustrated easily when writing code that I'm either going to throw away, or need to largely restructure or refactor later.  So I'd rather see slower results in the beginning if it means that when I do see my first result, it'll be closer -- hopefully! -- to what I think will be the final state of things.

I don't think either approach is better or worse, just different.  Well, with your approach I think there's maybe more opportunity to consider and come up with different possibilities for the final state as you go along, so that's definitely an advantage there.  But I've usually found that I can trust myself to come up with something pretty decent up front, even if it's not the most ideal thing.

[snip]

> Regarding #ifdefs (which should rather be runtime checks, by the way),
> that's obviously a concern, but it can't always be avoided.

Yeah, they end up being both -- I have a few things that look like:

#ifdef GDK_WINDOWING_X11
if (xfw_windowing_get() == XFW_WINDOWING_X11) {
    // do some X11 specific thing
} else
#endif
#ifdef GDK_WINDOWING_WAYLAND
if (xfw_windowing_get() == XFW_WINDOWING_WAYLAND) {
    // do some Wayland specific thing
}
#endif

It might be a little overkill, since I expect most people's GTK libraries will be compiled with both X11 and Wayland support for a really long time, but it'll certainly make for much less work if the time comes when distros decide to drop one or the other.  Or I could see someone doing something custom (like an embedded environment or whatever) where they're only building support for one or the other.

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

Yeah, you can certainly get into a trap where you try to abstract over two things, but the two things are different enough that the abstraction ends up being difficult to work with, and #ifdefs (or even separate implementations) would actually be easier and cleaner.  I expect when you get to figuring out how to embed out of process panel plugins on Wayland (either the embedded compositor route, or using xdg-foreign/xdg-exporter, maybe), you may well run into that, and separate code might be the way to go.  But for xfdesktop, which is largely doing things like enumerating windows, looking at their titles and states, and enumerating workspaces, and watching for changes in all of those things, it ends up being pretty similar.

I just mostly finished debugging libxfce4windowing earlier this evening, and ported xfdesktop to use it, and I'm really happy with the results.  With the exception of the introduction of workspace groups, it's mostly just s/wnck/xfw/.  The cool thing is that xfdesktop (and its settings dialog) now works quite well on Wayland, after just a few days of work.  libxfce4windowing emulates a single workspace in the absence of the workspace protocol, and is also able to enumerate toplevels for the CDE-like minimized window desktop icons mode.  (It still needs a bit of cleanup, and there are some bugs and missing stuff, but it's fairly far along, and I'm really happy with the abstraction approach.)

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

Yeah, I can see why that would be a better approach for that task.  I also try to be mindful of the advice to never extract code into a library until you've proven the functionality and know it'll be needed in more than one place.  So I probably did jump the gun on that one, but I think in this case the prior art of libwnck convinced me that this was useful in abstraction-library form.

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

Yeah, that seems reasonable.  I think my preference for a generic abstraction would be for a separate library: I can see the utility of libwnck on its own, which has seen some good use in a variety of places.  And I'd maybe hope that what I've written might find use outside Xfce... there's currently nothing Xfce-specific in it, so I might even consider renaming it to something generic and releasing it on its own

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

Oh man, tell me about it.  I'm still very much a Wayland novice, and am picking up things as I go along.  I've actually been kinda negative on Wayland for a long time.  I would think: X11 works fine for me, for the most part, so why bother?  But I read something (https://artemis.sh/2022/09/18/wayland-from-an-x-apologist.html) written by someone I think has/had opinions similar to mine on this, and it made me want to take a fresh look.

I also got a new Framework laptop recently, and, well, to avoid making this already-long email even longer, I'll just say that HiDPI is a mess, and it's basically impossible to scale the UI & fonts in a way that satisfies completely (plus I have to undo some of my scaling settings whenever I plug in an external monitor or start a fullscreen game).  On X11 I honestly don't expect this situation to ever be fixed, but it feels much more likely that this could work properly on Wayland, even if it requires more work to get there.

There are other likely-unfixable annoyances I have with X11, but I've already droned on long enough in this email ;)

     -brian