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
