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 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. -- Thomas [0]: https://bsd.network/web/@thomasadam/111818731342577284
