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.
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.