Not OP, but modularity. An X11 WM is just a WM. You can choose compositor, bar, shortcut daemon, etc. With Wayland, a single implementation holds most of that, and more. If you need a specific feature from your display server, you are stuck on WMs that support it. This has forced me to use KDE for Wayland on my main workstation, and although it works well, it’s not my prefered WM/workflow.
Alongside that, no clones of several X11 WMs exist. bspwm for example. Riverwm exists, but has major limitations, and the workflow isn’t the same.
In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.
The status bar example holds for xorg as well… What wm doesn’t ship its own bar nowadays? The only one I can think of is bspwm. But nothing stops you from disabling the native bar and using your own
Trying to replace KDE’s task bar is quite more involved than exchanging all those minimalist bars for tiling wms, it’s way more tightly integrated. It is a separate process even on wayland, though, so the API to e.g. get live video previews of windows is exposed, in principle anyone can use it as long as KDE spawns you as a task bar and thus grants you access to the API. Which is probably just a matter of changing an obscure config file somewhere, they never hardcode such things.
And if you’re comfortable with them changing the API under your feet because they probably didn’t submit it on the standards track because, as said, the whole ecosystem isn’t exactly mature, DEs themselves are still figuring out how to best do things and to establish a standard they actually have to agree on a common approach. There’s no taskbar stardard for X btw, either, or at least xmobar is being fed a proprietary format string via fifo every update. It’s basically just a fancy text box.
With a library like Wlroots you almost get that, it’s just in-process rather than out of process. The real problem there is doing some fancier things requires nonstandard Wayland extensions with low support across the ecosystem.
Not OP, but modularity. An X11 WM is just a WM. You can choose compositor, bar, shortcut daemon, etc. With Wayland, a single implementation holds most of that, and more. If you need a specific feature from your display server, you are stuck on WMs that support it. This has forced me to use KDE for Wayland on my main workstation, and although it works well, it’s not my prefered WM/workflow.
Alongside that, no clones of several X11 WMs exist. bspwm for example. Riverwm exists, but has major limitations, and the workflow isn’t the same.
In practice wayland is way more composable that one would, at first glance, expect, and even accidentally so, because DEs are made up of different components often sharing common interfaces, so the cosmic task bar will run under the sway compositor and suchlike. Not just “run” as in “not crash” but “actually display tasks based on information from the compositor”. I expect further standardisation there once the ecosystem matures a bit more. Just because you can include a task bar directly in the compositor process doesn’t mean you have to, and the same goes for window rules, window decorators, whatnot.
The status bar example holds for xorg as well… What wm doesn’t ship its own bar nowadays? The only one I can think of is bspwm. But nothing stops you from disabling the native bar and using your own
xmonad doesn’t, though using xmobar is common.
Trying to replace KDE’s task bar is quite more involved than exchanging all those minimalist bars for tiling wms, it’s way more tightly integrated. It is a separate process even on wayland, though, so the API to e.g. get live video previews of windows is exposed, in principle anyone can use it as long as KDE spawns you as a task bar and thus grants you access to the API. Which is probably just a matter of changing an obscure config file somewhere, they never hardcode such things.
And if you’re comfortable with them changing the API under your feet because they probably didn’t submit it on the standards track because, as said, the whole ecosystem isn’t exactly mature, DEs themselves are still figuring out how to best do things and to establish a standard they actually have to agree on a common approach. There’s no taskbar stardard for X btw, either, or at least xmobar is being fed a proprietary format string via fifo every update. It’s basically just a fancy text box.
With a library like Wlroots you almost get that, it’s just in-process rather than out of process. The real problem there is doing some fancier things requires nonstandard Wayland extensions with low support across the ecosystem.