Re: FVWM: fvwm3? [on Wayland]
At Sun, 4 Feb 2024 09:51:45 +1000 Stuart Longland wrote: > > On 4/2/24 08:05, Thomas Adam wrote: > 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) Looks/functionallity: I want the MWM look/functionallity. > - Are people using FVWM for its binding/scripting support? > - Are people using FVWM for just being light-weight? YES! I want as lightweight a window manager as posible. I don't want to have to a super powerful computer, just because of my GUI. Some of the GUI tools I use are more then "bloated" enough without having to add a "bloated" memory hog just to manage a few windows. > > 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. -- Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364 Deepwoods Software-- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services hel...@deepsoft.com -- Webhosting Services
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
Re: FVWM: fvwm3?
On Fri, Feb 02, 2024 at 10:42:37PM -0600, Jason Tibbitts wrote: > Now, I don't know if you could use the really old-style remote display > stuff where ssh is not involved. Xwayland really is a proper X server > so the ability to do it is probably down in there somewhere. Yes-and-no -- in that, although XWayland is similar in architecture to Xephyr and Xnest, it's not anywhere near a complete "stripped-down" XServer -- Xephyr has better support for a lot of the XServer extensions than XWayland does, and I suspect that will only ever support enough to run pure XLib/Xaw applications, and nothing more. Certainly, running fvwm under XWayland is possible, but because of the RandR support available, it doesn't recognise the host's screens, and hence doesn't work how you'd expect it to at present. Beyond that limitation, there's still plenty of other extensions which would be needed to make fvwm run comfortably under that. You'll probably find plenty of rhetoric on Youtube and elsewhere showing some $WM running under XWayland -- the point here is that such a $WM is not a reparenting WM, and relies on just drawing window borders around clients, which is very different. Speaking of the Wayland architecture, and having read others' replies in this thread, it's saddening to think of the shear lack of understanding there is between Xorg and Wayland. When people talk of a "port of FVWM to Wayland" they do so in the naive understanding that it's already possible -- with there being an existing framework or something which would make the possible. There is not. FVWM amongst the existing X11 WMs is already unique in that it has been built against pure X11 -- that is, no existing higher-level widget toolkit to provide window decorations, such as GTK or QT. Rather, FVWM is a *reparenting* window manager, which means its window decorations are drawn via Xlib, and the client window is embedded inside that frame, drawn via fvwm, via Xlib. That's what reparenting means. When you go to resize, move, etc., a window managed by fvwm, you do so by that parent frame telling the client about its new size/geometry. All of this is via the XServer. With Wayland, and if there were to ever be a fvwm compositor, the *compositor* is the "server", as well as everything else. There is no longer a separation of client/server under Wayland -- a compositor must do it all in one. There are libraries which will assist with this -- such as wlroots. This has meant a lot of compositors function in the same way, such as river, dwl, labwc, sway, etc. But they all suffer the same problem in that they're only as good as the functionality this library provides, which is not everything which is part of the Wayland ecosystem -- albeit that is in itself in a state of flux. Although Wayland compositors have the separation to handle CSDs (client-side decorations), and SSDs (server-side decorations), the SSD code in compositors is nothing more than drawing a window frame around a client window, and moving it relative to the client -- this is because of the lack of reparenting under Wayland. Perhaps one of the biggest drawbacks of Wayland which worries me is that there is a notion of things called "portals" which are additional bolt-on bits of functionality which Wayland compositors can choose to implement or not. But by themselves, they're not addressing anything near what they should -- and when you compare them to what the ICCCM2 and the EWMH specification standardised on, it's all very much a step-backward in terms of richness and how windows should behave. Indeed, these "portals" seems to popup sporadically, and are not being addressed in a way which I would argue is cohesive. I mentioned over on Mastodon one such example of this [0] where a portal for specifying the miniicon (to use fvwm's parlance) turned into an utter shit-show because of the amount of bikeshedding involved. If that is the level at which progress is to be measured, Wayland is doomed. But right now, if portals under Wayland are meant to selectively bring over functionality found in the EWMH spec, it's a million miles away from being complete. Even if there were a cabal of compositors which were trying to do this collectively -- even in the spirit of how this were being done on X11 originally -- it's still very much up to the individual compositor to implement this, as there is no sever/client model to abstract some of that away. The best one might hope for is something like wlroots implementing these portals. Good luck with that. So, a "port" of fvwm to Wayland? No. Impossible. Because of the architecture, the reliance on the server/client architecture, the fact that there are no 2D graphics libraries which are standalone from Xlib which work on Wayland to generate window frames, makes this difficult (XFillRectangle, etc). There is notion of reparenting under Wayland. Wayland is not Xlib. I have been, in my spare time, looking at the XServer code and all
Re: FVWM: fvwm3?
Lucio Chiappetti wrote (Sat, Feb 03, 2024 at 01:53:29PM +0100): > I hope to be able to go on with Xorg until I live. Amen! :-)
Re: FVWM: fvwm3?
On Fri, 2 Feb 2024, Robert Heller wrote: Afterall, no one needs more then one computer... I suppose there is a smiley missing after the sentence :-) My usual way of working (post-COVID, from home) involves usually one or two ssh sessions on two different remote work machines. Quite occasionally I also activate a VNC viewer with a remote session of a VNC server on one of the work machines, and run X stuff there. Occasionally I also run a point-to-point VPN work-home and NFS mount over it, I rsync stuff from work to home, work on it at home, and rsync back when finished. Very rarely I edit work files over remote X, and even more rarely over remote NFS, but that's because I think my connection is low for that. At work I used regularly edit across machines over NFS, ssh and occasionally remote X (but all machines are on a LAN ... some on different VLANs and I have even expect gatewayed scripts to bypass that) Independently of all that, I've never considered switching to wayland, and do not think any colleague does. Our recent standard installation at work is Xubuntu (it used to be OpenSuse), and I had it mimicked on both the home desktop (20.04) and home laptop (22.04) ... first thing I did was to imstall also fvwm, and then run my good old .fvwmrc with the Minimum Necessary Change. I hope to be able to go on with Xorg until I live.
