well, isnt that just Xwayland?
this post was submitted on 28 Aug 2024
18 points (90.9% liked)
Linux
48328 readers
652 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
It's possible to do but also probably not worth the amount of effort to reimplement all of those protocols only for super old WMs that don't have a Wayland equivalent. None of them are particularly complex, so It's probably easier to just port those to wlroots than implement the compatibility, and it's an opportunity to make an API or library to make it easy to write WMs.
Creating a wayland compositor based in wlroots is much more work than an X11 window manager. And then there's quite a bit of work to keep up with new Wayland protocols.
But I personally don't think there's a need for more compositors, since the existing compositors do support all kinds of tiling.
E.g. river has custom layout providers, which allows for creating completely custom tiling behaviour. There's even a hyprland plugin which implements river-layout-v3.
None of them are particularly complex
Points to AwesomeWM and its lua lain libraries that will all need to be rewritten for Wayland.
I haven't looked into it particularly deep but it's not like there's a ton of stuff a WM can possibly do unless the code base is littered with raw X11 calls everywhere.
Most of the window placement and tiling logic shouldn't be tied directly to X11 and only a small part of it should really be interacting with X11 to place and size windows. So one should target that intermediate spot that makes all the X11 calls.
And if the code is too shit to port, it probably deserves to die.
There are quite a few niche window managers and desktop environments that it'd be a shame to loose. I'm quite fond of Windowmaker (and curious about Afterstep), Trinity DE, and NSCDE for example, and I'm not aware of Wayland plans for any of them.
TDE has had occasional discussion and ruminations, but no action yet. Porting it is complicated by the fact that it has its own widget set (TQT, forked from QT3), which would have to be worked on first and is currently undergoing some unrelated rewriting.
The likelihood of any wayland milestones for TDE being set before the end of 2024 is very low unless some major distro completely drops X support.
Window maker is indeed amazing and would be a shame to loose. It was my go-to back in the day.
We have kind of something like that with XWayland.
Interesting read at topic https://wayland.freedesktop.org/docs/html/ch05.html
An X11 application connects to Xwayland just like it would connect to any X server. Xwayland processes all the X11 requests. On the other end, Xwayland is a Wayland client that connects to the Wayland compositor.
The X11 window manager (XWM) is an integral part of the Wayland compositor. XWM uses the usual X11 window management protocol to manage all X11 windows in Xwayland. Most importantly, XWM acts as a bridge between Xwayland window state and the Wayland compositor's window manager (WWM). This way WWM can manage all windows, both native Wayland and X11 (Xwayland) windows. This is very important for a coherent user experience.
There is also rootless mode.
In rootless mode, each foreign window is a first-class resident among the native windows. Foreign windows are not confined inside a native window but act as if they were native windows. The advantage is that one can freely stack and mix native and foreign windows, which is not possible in rootful mode. The disadvantage is that this mode is harder to implement and fundamental differences in window systems may prevent some things from working. With rootless Xwayland, the Wayland compositor must take the role as the X11 window manager, and one cannot use any other X11 window manager in its place.
That's the toolbox we have right now. To make existing X11 window manager work exactly as before on Wayland would be another level. And why we? It would make Wayland way more complex than it is and if we want to use old software anyway, why do we develop Wayland at all? (The "WE" is not me, i'm speaking for devs.)
Some existing X11 window manager are already working on XWayland (think of Qtile) or are ported over right now. The simple ones could be rewritten from scratch, even if its not exactly the same (think of Sway). There will be some left. But that's okay. Window manager itself are not hugely complex and different from each other, only a few logic and the language differs greatly. We have already lot of variety. It's not like we would leave KDE or Gnome behind.
My opinion: We don't need to make Wayland even more complicated (for Wayland devs and for compositor and app devs), just for a few legacy tools.
I don't think Qtile works off XWayland. IIRC, it's a proper rewrite using pywlroots.