KDE/KWin On Wayland To Use Server-Side Decorations

[smitty3268]

To me, SSDs seems like a solution in search of a problem. All the negatives people list about CSDs seem pretty unimportant and easily bypassed to me.

But then, I don't really care about it much. If KWin wants to try providing SSDs on Wayland, then that's fine with me. We'll see how it works out.

[asdx]

Cool, Arch Linux is going to start shipping Wayland/Weston in the repos soon:

https://mailman.archlinux.org/piperm...ry/024422.html

[curaga]

To me, SSDs seems like a solution in search of a problem. All the negatives people list about CSDs seem pretty unimportant and easily bypassed to me.

Can you elaborate on that?

In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.

[Nobu]

Can you elaborate on that?

In particular Martin's point about very inconsistent decoration _will_ happen in a CSD system. How would it be easily bypassed without going SSD? The hypothetical libdeco is no solution, we both know every toolkit will have their own solution, as will every app started before toolkits get the functionality.

Inconsistent decoration _will_ happen in a SSD system, too. However, I have no reason to believe kwrite and gnome-terminal will suddenly decide to create their own decorations just because we switched over to CSD. Not only is it stupid, but it also means they will have to (each) write their own controls and hook them into their program themselves. Talk about code duplication.

No, most programs will continue as they have, and allow the other layers to handle decoration. There will be exceptions, as there are now (__with SSD__), but I believe they will remain the minority.

[Rigaldo]

Maybe settle for a "middle-ground" in the end?
Like, Wayland provides a library to make/render decorations, which also is themable. Even better, it can provide capability to add a button/menu or whatever in the decoration to "increase creativity" for those who want it.(It would need to care for cases like window shading and undecorating windows that have extra stuff in the decoration of course.)
So the application(actually its toolkit) would use this library to render the decoration in the same texture. But the server/compositor can still "command" the decoration through said library. So shading a window should still be possible, without coding it in the app. You can still have a single texture coming from a window and less IPC. And applications can look consistent(global theming of decoration, just like now). Specifically for the latter,there would be a default theme and the app can still force/request a certain theme, but the compositor optionally can do so as well, and the latter would always come on top in this case(so he compositor would decide if it let's the app choose or not).
I think it's should be possible, then we should get the best of both worlds. We shouldn't have to only look at two extreme ends, there's always the middle too.

[curaga]

Inconsistent decoration _will_ happen in a SSD system, too. However, I have no reason to believe kwrite and gnome-terminal will suddenly decide to create their own decorations just because we switched over to CSD. Not only is it stupid, but it also means they will have to (each) write their own controls and hook them into their program themselves. Talk about code duplication.

No, most programs will continue as they have, and allow the other layers to handle decoration. There will be exceptions, as there are now (__with SSD__), but I believe they will remain the minority.

What exceptions there are (Chromium and friends) can still be forced to use the system/wm decorations in a SSD system. Such won't be possible in a CSD system unless I'm mistaken.

[Ericg]

What exceptions there are (Chromium and friends) can still be forced to use the system/wm decorations in a SSD system. Such won't be possible in a CSD system unless I'm mistaken.

It probably wouldn't be too hard to set it up where IF they have client-side-decorations, they can use them, UNLESS the compositor has a specific setting set to true. Such as Kwin might have "Force consistent window decorations." as a true/false setting. Which would let the apps THINK they had CSD but would override them with SSD if set to true. If false then Kwin would provide decorations unless they had some built in.

[silix]

It probably wouldn't be too hard to set it up where IF they have client-side-decorations, they can use them, UNLESS the compositor has a specific setting set to true. Such as Kwin might have "Force consistent window decorations." as a true/false setting. Which would let the apps THINK they had CSD but would override them with SSD if set to true. If false then Kwin would provide decorations unless they had some built in.

it's not (only) a matter of aesthetics or user preference
as mentioned earlier, for KWin there's also the matter of providing window tabbed grouping, which is something that could be handled client side if windows all belonged to the same application (as the application would know about the windows, their number and their names), but would lose application isolation and complicate the protocol in the case of different applications (because one should know about the others, handle tab group enter/leave notifications, have access to the whole window stack) - so this case needs to be handled in the server / compositor

so an application running under Kwin could and would use CSD, but SHOULD switch to SSD when tab grouped - thus it would have to support both anyway (for KDE at least)
otoh, since putting a window in a tab group this is an external action initiated by the wm/compositor, asynchronously for the application, it would be the compositor telling the application to disable (on tab group enter) or reenable (on tab group leave) CSD's, rather than the application requesting them (apart from maybe the initial window creation)

oh and lets not forget windowed games (especially FPS's..), those hardly have a decoration of their own...

[Rigaldo]

New blog post regarding decorations ..
Quick, new article!

[Ericg]

New blog post regarding decorations ..
Quick, new article!

Kind of sounds like my idea above-- let the user choose, hybrid approach is gonna be the best option.