KDE/KWin On Wayland To Use Server-Side Decorations

[phoronix]

Phoronix: KDE/KWin On Wayland To Use Server-Side Decorations

Martin Gr??lin, the well known maintainer of KDE's KWin window manager, has shared that when ported to Wayland the KDE window manager will be using server-side decorations. It's commonly represented that Wayland requires client-side decorations, but this isn't entirely the case...

http://www.phoronix.com/vr.php?view=MTI5NjY

[hiryu]

yay

While I'm happy to hear this (and it's also old news). What exactly are the drawbacks off server side decorations in wayland. It's not entirely clear what the issues (aliasing issues? why? can this be fixed in wayland?).

[zanny]

While I'm happy to hear this (and it's also old news). What exactly are the drawbacks off server side decorations in wayland. It's not entirely clear what the issues (aliasing issues? why? can this be fixed in wayland?).

The only reason window decorations were pushed outside of Weston (remember, Wayland is a display protocol backend that doesn't care how you use it) I think was for simplicity.

I do strongly agree with this, that Kwin should manage window decorations. I am always of the impression an application should, at least by default, be blind to its execution environment, and know as little as possible - a gui app should know the size of its window, and whether it has focus, and that is it (if window = 0x0, you are minimized, or some such). The rest can almost always be managed by the window manager, and for things like launcher integration / external binding those should be managed by dedicated separate APIs.

[nerdopolis]

While I'm happy to hear this (and it's also old news). What exactly are the drawbacks off server side decorations in wayland. It's not entirely clear what the issues (aliasing issues? why? can this be fixed in wayland?).

I think the main fear with server side decorations is it requires more inter process communication, as the server side decoration would have to be sized up against the window as it's being resized, the server would have to resize the decoration surface as well. Not only would this increase IPC,

And don't quote me on this, but I would also think that it would require the application to tell the server more about its surface, such as the window is resizable, or closable, so that the server (or separate decoration program, however it's implemented), so that it would know not to draw a close button on the decoration, or maximize button, or make the borders not re sizable.



This being said, there would have to be a protocol to tell applications not to draw their titlebars for kwin to do this...

[Awesomeness]

Finally someone talking some sense. I felt like I was the last sane person on the planet after local Wayland fanboys here tried to argue over and over again that CSD were superior.

[hiryu]

The only reason window decorations were pushed outside of Weston (remember, Wayland is a display protocol backend that doesn't care how you use it) I think was for simplicity.

I know it was done for simplicity, but what makes client so much simpler in the context of the wayland protocol? My understanding is that there's an elegance to it as the windows can be drawn as a single texture.

So from the article it says drawing windows as a simple texture in Weston allows you to have no aliasing when rotating the windows, etc. Why can't this be the case with server side windows? Or is it just trickier?

[Nobu]

The only reason window decorations were pushed outside of Weston (remember, Wayland is a display protocol backend that doesn't care how you use it) I think was for simplicity.

I do strongly agree with this, that Kwin should manage window decorations. I am always of the impression an application should, at least by default, be blind to its execution environment, and know as little as possible - a gui app should know the size of its window, and whether it has focus, and that is it (if window = 0x0, you are minimized, or some such). The rest can almost always be managed by the window manager, and for things like launcher integration / external binding those should be managed by dedicated separate APIs.

Generally, applications wouldn't know anything about the theme anyway; most of that is handled by the tool-kit (Qt, in this case). There are exceptions, of course, but most developers don't care to mess with that. You could probably achieve the same thing the KDE guys are doing with CSD, but I guess they've found it to be (or, believe it to be, at least) simpler to have the compositor handle it instead.

Edit: That's true for themes, anyway; tool-kits don't handle decorations (yet?), so I guess that also factors in. I still don't understand why nobody will write simple library whose sole purpose is drawing window-decorations into a buffer provided by the tool-kit for the window. Simply tell the tool-kit how big your decorations are, and the extra space can be created when making the buffer, then the library writes to that buffer (or it's own buffer, and hands it to the tool-kit to merge), and boom! Decorations.

Alternatively, the library tells the tool-kit how big the decorations are, provides images/textures and tells it where they go, and the tool-kit does the drawing itself. Same result.

[not.sure]

Yeah, kudos to Gr??lin for talking some sense that doesn't blindly follow the hype du jour.

[Rigaldo]

Indeed, there could be a library included with Wayland with basic decoration support or providing an basic api to do them(but giving room to decisions to the other programs more concerned about how the decoration should be). Toolkits would use it to do the client side decorations and probably compositors too, when they want to do server side. And the compositor could likely set a parameter to get the library to do the decoration server side or client side(or put client side on and off simply). In case the app doesn't provide decoration, it could do a default fallback one. And thus we have decorations for all apps and compositors any way they want. It would be like simply switching the theme and would be an easy option to turn CSD on and off. And an application should optionally override the compositor, if the author so wants.(not 100% sure if that's a good idea though)
Of course I'm not a windowing system developer, so I don't know what could be "broken" this way.

[ninez]

I know it was done for simplicity, but what makes client so much simpler in the context of the wayland protocol? My understanding is that there's an elegance to it as the windows can be drawn as a single texture.

So from the article it says drawing windows as a simple texture in Weston allows you to have no aliasing when rotating the windows, etc. Why can't this be the case with server side windows? Or is it just trickier?

try to use 'wobbly windows' in kwin or compiz ~ you'll see just how terrible server-side decorations can be (the decoration / window won't line up properly and you have noticable lines/gaps between top of the window decoration and window, looks like absolute shite :\. Maybe all of this stuff is solvable, but for many years it has just continued to look more or less - absolutely wretched, to be candid. ~ so i guess the answer is that it is indeed 'trickier' to solve these issues, when you are working with 2 textures, rather than just one.

Personally, i think if they (not kwin developer, but other developers) can get CSD right. (by right, i mean better than windows), i would much prefer to leave server-side decorations behind. afaik, server-side has more overhead too (aside from also never looking quite right... although i am not an expert on WM) but does have the odd advantage too. But since, i don't use kwin this news doesn't exactly affect me (although kwin is pretty good), but i am definitely hoping for a decent CSD implementation in some compositing WM/DE, instead of server-side decorations. (that is if/when nvidia-driver can be used with Wayland...whenever that happens!..lol)