4 ms·

One thing I rarely see discussed - and one of the reasons I don't like Wayland personally - is the second order effect of putting everything in the compositor:

One thing I rarely see discussed - and one of the reasons I don't like Wayland personally - is the second order effect of putting everything in the compositor: It is now really hard to write a "window manager" or window tools. And this leads to a certain uniformity of desktop environments (the big ones, GNOME + Plasma, and then a bunch of keyboard driven minimal environments "for hackers") What I mean is, back in the day with X11, all clients were equal and there were nice little tools that let you switch between virtual desktops graphically (desktop pagers). I myself wrote a little taskbar (with the kind of glow animation that moves with the cursor that Windows 7 made popular), but never published it unfortunately. A lot of people wrote or hacked on window managers. It was never really easy, but at least it was possible. Now with wayland, you have to write not only the code that draws the titlebars, but the code that puts the pixels on the screen, input handling, clipboard handling and all kinds of stuff. Of course you can fork an existing window manager, or use something like wlroots, but they are all opinionated. If you just want "GNOME with different titlebars" someone else wants "KDE with different titlebars" - you're out of luck. So this makes the barrier to entry really high. On the other hand, if somebody would write a "window decorator" interface, you could write a small window decorator process (like we had with Compiz). I don't believe this will happen, because it would have to be adopted by multiple compositors to make sense. If it did, I would have a bunch of ideas I'd like to try out one day.

dashboardmess 6y ago
“Putting everything in the compositor” isn’t mandated by Wayland at all, and I think only gnome does it. If you implement the protocols defined by Kwin, you can reuse everything in KDE without using it. Yes, it’s a lot of work, but properly implementing it on X11 also is more work than you would expect. The only problem here is politics, as KDE hasn’t stabilized the interface as far as I know. Wlroots isn’t opinionated at all. In theory, it’s perfectly possible to write a gnome shell alternative using wlroots. Writing a taskbar for nearly all wlroots based compositors is also possible. You could even write a plugin for wayfire to implement the Kwin protocols, and write another plugin to implement a simple window manager. As for changing the titlebars, as long as you enable CSD, you could just write a theme.

dashboardmess 6y ago

“Putting everything in the compositor” isn’t mandated by Wayland at all, and I think only gnome does it. If you implement the protocols defined by Kwin, you can reuse everything in KDE without using it. Yes, it’s a lot of work, but properly implementing it on X11 also is more work than you would expect. The only problem here is politics, as KDE hasn’t stabilized the interface as far as I know. Wlroots isn’t opinionated at all. In theory, it’s perfectly possible to write a gnome shell alternative using wlroots. Writing a taskbar for nearly all wlroots based compositors is also possible. You could even write a plugin for wayfire to implement the Kwin protocols, and write another plugin to implement a simple window manager. As for changing the titlebars, as long as you enable CSD, you could just write a theme.