Re: FVWM: fvwm3? [on Wayland]

On 4/2/24 08:05, Thomas Adam wrote:
> Wayland is not Xlib.
> 
> I have been, in my spare time, looking at the XServer code and all the other
> libraries surrounding it, and looking at open MRs on Xorg's Gitlab instance --
> which means I am going to help keep XServer alive -- which by extension means
> fvwm.
> 
> For all the while that continues, when you hear about widget libraries such as
> GTK and QT dropping support for XLib, that's the time to worry -- as there
> could, in theory, be a time when Firefox or Chromium no longer run under X
> directly, without forcing a Wayland compositor.  That's the real
> nail-in-the-coffin.
> 
> So, I'll keep fvwm alive for as long as I can, but I really can't see how
> there could ever be a Wayland compositor.

I appreciate your efforts in trying to keep FVWM alive.  It has a long 
history… and so far, I've not found a more flexible window manager.

FVWM was always my go-to when supporting Gentoo/MIPS, because I could 
get FVWM built very quickly due to its Xlib base.  The others required 
me to build a GUI toolkit like Qt or GTK+, which meant no X11 
environment for a lot longer.

I've tried a couple of Wayland compositors, they seem to be at two 
extremes of the user experience space: either full-featured (and quite 
bloated) desktops such as Gnome or KDE Plasma… or extremely minimal 
tiling affairs.

Nothing that is "in between" like FVWM, which works just as gracefully 
on my relatively new Ryzen 7 5800U laptop as it does the 14-year old 
Atom N450 netbook.

I tried Plasma on the latter, I don't think I need to describe how it 
went.  On the laptop I'm typing this on now (Panasonic CF-53; 10 years 
old now), Plasma worked okay, but it still "felt" slower, and a lot of 
things I was used to were missing.

Window management is so much more than just drawing a box around a 
window and plonking it somewhere on a screen.

My understanding for the Wayland push is that the X11 driver 
architecture was written around assumptions about video hardware that 
existed circa 1986~1996 which almost universally were built around CRT 
sync hardware.

That assumption is starting to fall apart with some of the modern video 
hardware out there that outputs a digital packet-based stream via HDMI 
or DisplayPort.  Apple Silicon hardware in particular, seems to bear 
little resemblance to what came before, and hence the Asahi Linux team 
decided they weren't going to support X11.

While there are people still working on X11, many of them are starting 
to tire of the work because it's specialist code that requires a deep 
understanding of both X11 and graphic card hardware to be effective.

So either some of us need to step up and get familiar with how X11 works 
(unlikely, it seems like a monumental task)… or we need to "pack our 
bags", so to speak, and move to a new world: FVWM on Wayland is 
basically going to be a re-write.  Can we re-use certain modules to 
emulate what we had?  I don't know.

A big part of FVWM was its script-ability.  It could hook various 
events, then you the user, could program it to automate what happened 
next using a domain-specific language.

e.g. I have FVWM here set up so when I hit the "Super" key; a menu pops 
up.  If it's on a window, the menu that pops up has window operations up 
the top (Close, Move/Resize, Maximise, Split…) followed by a "Quick 
Launch" (which lets me quickly access specific applications) and access 
to the root menu (to reach everything else).  On a non-window, the menu 
that appears has just the latter parts (there's no window to operate on).

So if I want to make the current window occupy the right-half of the 
screen, I hit Super, L (for Split), 2 (for Half), R (for Right).  If I 
want it the lower-right quadrant, it'd be Super, L, 4, R (bottom right).

A single keystroke brings up a menu tree, then keyboard mnemonics on 
menu items lets me navigate that menu to a specific item; which calls 
FVWM actions do the rest.

I'm not sure how others use FVWM, but this is how I use it, and I find 
it is a huge productivity enhancement.  I'm not bothered much about how 
it looks (I do insist on a title bar: my windows look like MWM), but a 
big part is being able to move things around.

I think this is where we need to consider what the FVWM/Wayland re-write 
would look like.  What can be practically brought across under the 
constraints of the `wlroots` back-end (or Wayland itself), and what do 
we have to leave behind?  Of the things we can bring across, what items 
are of most important to people?

- Are people using FVWM for its looks?  (Themability)
- Are people using FVWM for its binding/scripting support?
- Are people using FVWM for just being light-weight?

I think this is what we need to be asking, what is important to us, the 
FVWM community that we want to preserve?  Then we can figure out how 
best to bring across enough of the FVWM "essence" to build a new home in 
the land of Wayland.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.