On Thu, Feb 08, 2024 at 05:50:44AM +0100, hw wrote:
> I still don't see why it shouldn't be possible. I never expected a
> port, and I understand that the architectures of X11 and Wayland are
> very different. Yet why shouldn't it be possible to create a
> compositor that provides the configurability fvwm has and which is so
> badly lacking in Gnome and KDE?
Absolutely it is possible. But then it wouldn't be fvwm.
> Is it really impossible to create a wayland compositor that provides
> the required functionality?
I'm not entirely certain you've understood the points in my original email.
I also don't want to repeat myself, but...
To me, the things which make fvwm unique, are:
1. Its architecture is tied to X11 -- it uses Xlib directly to render window
frames. This is all using Xlib's graphics backend which has a large array of
2d drawing routines. There's not a separate library which can be used to
abstract this out to be used elsewhere -- this is the entire point of the
client/server model in X11.
The only thing which comes close is libcairo (built on pixman) -- and you can
use that with a wlroots-based compositor to generate "SSDs" within a
compositor -- but this doesn't work well for fvwm because it doesn't allow for
shading when filling in rectangles, as well as various other things.
This is important because, for me, the entire point of fvwm is that it can be
made to look like MWM. I'm serious here -- all of that blocky (even "ugly",
as some people have called it) looking borders is important to me, that's what
I like.
2. Even if 1., were a solved problem, the second issue is a lack of
reparenting. This is a core feature of xlib, and fvwm makes extensive use of
it to be able to function. It makes things like resizing and moving windows
easier. It's also very important for FvwmButtons; the "Swallow" command calls
XReparentWindow() directly.
I'm really dumbing-down the explanation here, but it's not possible on Wayland
at present. I suspect it will never be.
Now, even if the graphics side of things from point 1 above were currently
possible under Wayland, the lack of reparenting means you're having to move
the window frame along with the window itself -- the two are not "connected",
which causes all manner of weird glitches.
3. Lack of standards a la ICCCM/EWMH
Fvwm is the exemplar project for how implementing standards helps
interoperability rules for window governance. Again, because of the X11
architecture, the XServer would make this easy. Under Wayland, there's
"portals" but they're now selective about what's being implemented. So things
like aspect-ratio resizing doesn't have a portal. There's so much in the
EWMH which makes fvwm behave the way it does with applications, until that's
addressed -- or if it ever is -- you'll probably notice lots missing from a
potential fvwm-compositor under Wayland.
Let's not forget though that fvwm being a reparenting window manager was
always making it an outlier. Widget libraries like GTK and QT have gone way
beyond just providing UI components -- they're now also responsible for CSDs
and a myriad of other crap -- and when you put that into context of what a
Wayland compositor needs to do -- it has fewer options. Styling and theming
becomes the same across Wayland compositors. So you're losing out on a lot
with the Wayland architecture being what it is, alas.
So Wayland is going to be dominated by Gnome and KDE. Yes, they'll be smaller
tiling-only WMs on Wayland, but they'll all look the same.
So I hope this answers your question. I shan't be replying to any more emails
in either this thread, or the other one which is talking about Wayland. The
subject is becoming tiring and laboured, with most people just saying the same
thing, without the understanding behind it.
Kindly,
Thomas
