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.
