|
|
|
|
|
|
by rollcat
913 days ago
|
|
|
> This is the core problem I have with Wayland. There is no "Wayland server", just as there are no window managers. It's _just_ a protocol.
>
> Wayland has conflated those two concepts by making every Wayland compositor have to do both roles. This is fine. Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here. IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver. You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects. Focus on what users actually need from the applications (like: working screen capture). X11 - the platform with more window managers and terminal emulators than actual apps. Wayland needn't repeat the same mistakes, but here we are on that trajectory. > KDE in Wayland and Gnome in Wayland most likely share zero lines of code (I haven't looked, so I don't know for certain). Close enough. We have kwin, Mutter, and wlroots (the last one effectively doing what Weston should have done from the start) - three disjoint codebases. Gnome telling SDL2 to link to libadwaita to draw clientside window borders is just cherry on top. |
|
|
> Every windowing system in common use (and a dozen others) took that path. X11 is the odd thing here.
Every other graphical system did so by tying the protocol to an entire specific software stack; Windows/Android/MacOS/Haiku all require you to use their single official compositor and window manager. I get that you're arguing that's a good thing, but I pretty strongly disagree.
> IMHO the actual strategic mistake for Wayland was that they prioritized writing standards over iterating on a working reference implementation that was usable as a daily driver.
Hard agree, 100% yes; even if they'd just focused on shipping a single working example desktop environment, at least it would have forced them to figure out all the protocols that need to exist.
> You shouldn't need an alternative window manager any more than you would need an alternative trackpad firmware. It's supposed to be invisible. Draw the window borders using a plugin/subprocess, because your existing user base demands shallow "customization". Cover the 99% use case, and expose an API for extensions to do stuff like auto-tiling or shader effects.
I'm less convinced of that; people aren't asking for shallow customization at all, and I am skeptical of the idea that any one window manager could accommodate the needs of GNOME, compiz (yay cubes), and dwm. You'd also bake in technical choices that would sit badly with chunks of the population; odds are that we would have ended up baking most of GNOME into the graphical server and being stuck using javascript for everything, or gone the other way and committed to using C forever.
But overall, I tend to agree; personally I would have liked wlroots to effectively become the unifying point and have been part of the initial release, along with actually shipping most of the needed protocols up front rather than effectively leaving everything except drawing windows as a TODO.