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]

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.

[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?

[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)

[pingufunkybeat]

try to use 'wobbly windows' in kwin or compiz

I did, it looks fine. No artifacts.

[newwen]

Does Wayland provide a protocol to tell the compositor if the window is closable, minimizable, resizeable or if it lacks decoration at all? I'd think so, since server is also a window manager.

But what if you're running a wayland application what does client side decorations? Would Kwin render a window decoration on top of the Window (just like compiz is doing now for Chrome, for example)?

What if you want to run a KDE application on another wayland server that doesn't support server side decorations?

I believe, that wayland server should let the client decide if it wants decorations or not each window, but compliant wayland servers should implement both, client and server side decorations. Otherwise, compatibility among servers, toolkits and applications will be a mess. Weston is thus, a bad reference server right now. Kwin is also a bad server if it doesn't allow CSD.

Wayland compliance should enforce supporting both SSD and CSD

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