On Thu, 2024-02-08 at 18:10 +, Thomas Adam wrote:
> 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.
Maybe --- I don't understand why it shouldn't be possible to make am
fvwm that works with wayland. I can understand that wayland refuses
to manage windows which might make it difficult to do that, yet it
seems to work with gnome.
> 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.
Are you saying it's impossible with wayland to draw stuff like window
decorations on a display and only X11 can do it? It seems to work
just fine with gnome.
> 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.
That doesn't seem to be an issue; I can move windows in gnome.
> 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.
What I'm missing in gnome is configurability, and not only in regard
to the window manager (and it doesn't really matter if it's called a
compositor). So I don't see how ICCCM/EWMH would be relevant; I can
only assume they aren't available with wayland, and yet things are
working without.
> Let's not forget though that fvwm being a reparenting window manager was
> always making it an outlier.
So does that mean that reparenting is a feature almost no window
manager made use of except fvwm? Haven't they been able to do their
job because they didn't use this feature?
> 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.
Isn't it one of the purposes of such libraries that GTK looks like GTK
and QT looks like QT? The software that doesn't use them also looks
like it doesn't (i. e. like Xlib or xaw). And are you being forced to
use these libraries?
> So Wayland is going to be dominated by Gnome and KDE.
I thought it's the other way round.
> 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
