Yes, actually; the X server was awful, but it was a single contained point of awfulness that allowed everything else to be trivially interoperable. Breaking that apart could have been good except that the way they actually did it mixed far too many concerns into the graphical server (compositor), so while we have more of them, in practice you can't actually mix and match the rest of the system anymore.
Not sure what you mean; wlroots still assumes that the window manager and compositor is in the same process. Wayland itself assumes that those things are also in the same process as the display protocol/server.
With X11, if someone wanted to write a window manager, they could do that and only that, without having to write a compositor or display server. Wlroots certainly simplifies those latter two bits, but there's still a lot of work to do to use it.
Beyond that, Wayland's mess of extension protocols are generally incomplete. I've been working on "porting" parts of Xfce to Wayland, and there are a significant number of things that just cannot be done at all right now without integrating it directly into the compositor process. The extension protocols necessary to do even a fraction of this table-stakes stuff are often experimental or non-standard, and even when they do exist, are often missing critical pieces.
As an example: say you want to write a dock-type app that only shows the list of toplevel windows present on the current workspace (and when you switch workspaces, it'll show the windows on the new workspace). Nope, you can't do it. The workspace protocol itself has been languishing in Freedesktop GitLab[0] for two and a half years, and even if that was standardized, it doesn't interact with the Foreign Toplevel protocol at all, so you have no idea what windows are on which workspaces.
So currently the only solution is: your dock app has to live in the same process as the compositor, where it has access to all the compositor-specific data around workspaces and windows. (Sure, you could build a d-bus interface, or something like that, but that would be specific to your one compositor... and a d-bus interface is the moral equivalent of a Wayland protocol, which is what you should be using anyway.)
It is a display protocol, responsible for displaying things. A compositor is a must for that
Er, are we using different meanings? Obviously something has to display pixels, but I literally do run X without a compositor.
a window manager, and there is no reason why that can’t be done with this model (and is pretty much what wlroots does).
No, you can't (excepting rootfull xwayland, obviously), Wayland forces the display server, compositor, and window manager to be a single program. All wlroots does is make it easier to write that compositor, it hardly changes the model.
The price is tearing. Which may not be too noticeable at 1920@60fps, but playing a video on a bigger screen at higher refresh rate will very very seriously tear. It is not an accident that every other OS is compositor-only.
Wayland forces the display server, compositor, and window manager to be a single program
Only the first two. You can allow a third-party program to control your windows’ state via any IPC mechanism you choose.
Sure, there are trade offs in skipping the compositor. But the claim was:
It is a display protocol, responsible for displaying things. A compositor is a must for that, it is not additional complexity at all.
Which is just false; a compositor isn't a must unless you move the goalposts beyond "displaying things".
You can allow a third-party program to control your windows’ state via any IPC mechanism you choose.
I guess you could, by adding a lot of API surface; has literally anyone ever done this, or is it just a hypothetical solution? Because I'm not aware of any existing compositor that lets you plug in a window manager.
Wayland compositors have provisions for skipping the compositing part when a single client is running full screen. So, by your argument, Wayland is also "not a compositor".
I don't think that follows. You can run a fully-functional X session, with an arbitrary number of windows, without any compositing. It's not some special case reluctantly added after people pointed out that the initial "you must fully double-buffer every single pixel every single time" wasn't actually universally a good idea. But even at face value... okay, so you'd like to extend the argument to say that not even Wayland actually forces you to composite? Because that's agreeing with my argument, just more strongly.
Comments
Yes, actually; the X server was awful, but it was a single contained point of awfulness that allowed everything else to be trivially interoperable. Breaking that apart could have been good except that the way they actually did it mixed far too many concerns into the graphical server (compositor), so while we have more of them, in practice you can't actually mix and match the rest of the system anymore.
It is a display protocol, responsible for displaying things. A compositor is a must for that, it is not additional complexity at all.
What you would want to mix is a window manager, and there is no reason why that can’t be done with this model (and is pretty much what wlroots does).
But I do agree that a cathedral model can have benefits.
Not sure what you mean; wlroots still assumes that the window manager and compositor is in the same process. Wayland itself assumes that those things are also in the same process as the display protocol/server.
With X11, if someone wanted to write a window manager, they could do that and only that, without having to write a compositor or display server. Wlroots certainly simplifies those latter two bits, but there's still a lot of work to do to use it.
Beyond that, Wayland's mess of extension protocols are generally incomplete. I've been working on "porting" parts of Xfce to Wayland, and there are a significant number of things that just cannot be done at all right now without integrating it directly into the compositor process. The extension protocols necessary to do even a fraction of this table-stakes stuff are often experimental or non-standard, and even when they do exist, are often missing critical pieces.
As an example: say you want to write a dock-type app that only shows the list of toplevel windows present on the current workspace (and when you switch workspaces, it'll show the windows on the new workspace). Nope, you can't do it. The workspace protocol itself has been languishing in Freedesktop GitLab[0] for two and a half years, and even if that was standardized, it doesn't interact with the Foreign Toplevel protocol at all, so you have no idea what windows are on which workspaces.
So currently the only solution is: your dock app has to live in the same process as the compositor, where it has access to all the compositor-specific data around workspaces and windows. (Sure, you could build a d-bus interface, or something like that, but that would be specific to your one compositor... and a d-bus interface is the moral equivalent of a Wayland protocol, which is what you should be using anyway.)
[0] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
Er, are we using different meanings? Obviously something has to display pixels, but I literally do run X without a compositor.
No, you can't (excepting rootfull xwayland, obviously), Wayland forces the display server, compositor, and window manager to be a single program. All wlroots does is make it easier to write that compositor, it hardly changes the model.
The price is tearing. Which may not be too noticeable at 1920@60fps, but playing a video on a bigger screen at higher refresh rate will very very seriously tear. It is not an accident that every other OS is compositor-only.
Only the first two. You can allow a third-party program to control your windows’ state via any IPC mechanism you choose.
Sure, there are trade offs in skipping the compositor. But the claim was:
Which is just false; a compositor isn't a must unless you move the goalposts beyond "displaying things".
I guess you could, by adding a lot of API surface; has literally anyone ever done this, or is it just a hypothetical solution? Because I'm not aware of any existing compositor that lets you plug in a window manager.
Wayland compositors have provisions for skipping the compositing part when a single client is running full screen. So, by your argument, Wayland is also "not a compositor".
I don't think that follows. You can run a fully-functional X session, with an arbitrary number of windows, without any compositing. It's not some special case reluctantly added after people pointed out that the initial "you must fully double-buffer every single pixel every single time" wasn't actually universally a good idea. But even at face value... okay, so you'd like to extend the argument to say that not even Wayland actually forces you to composite? Because that's agreeing with my argument, just more strongly.