Modern desktop environments nowadays are facing critical dilemma regarding a basic design question. On the face of it, there appears to be two different kind of options laid before the developers:
Either go with the more conservative server side decoration (SSD) or alternatively the more flexible client side decoration (CSD).
What’s the Difference?
As explained by Ken Vermette, KDE developer / designer, you may think of it as if by saying SSD we mean that the window manager (e.g. Kwin) is in control of the decoration whereas when saying CSD we intend that the ‘App’ is in control of it.
Therefor, when the ‘App’ has the control, it gives the decoration more flexibility since each app can place the buttons wherever and however it wants to, whilst window managers, on the other hand, usually tends to be more consistent and straightforward about it.
‘Isn’t Linux is all about flexibility?‘ you say, well for the most part it is, however letting the ‘App’ have all that power in its hands can also present some drawbacks as well.
For instance, what happens when the App crashes and you can’t move or close its window? you’ll need to resort into console or task manager in order to kill it. Not very elegant…
Another good example is taken from a real situation you may have faced until recent with KDE’s competitor DE – GNOME which uses CSD by default;
It was up to version 3.12 that GNOME had consistency issues when handling its CSD among all the different kind of apps it has, i.e. minimize and maximize functionality needed to be returned.
So, upon reading the above you may come to the conclusion that each design has its pros and cons and neither is superior, right?
That may be true, but what if you could take the best of each world and combine it into a one integrated decoration solution? That’s exactly where KDE’s new DWD comes into the picture.
KDE’s DWD Window Decoration Concept
What is DWD? – Dynamic Window Decorations
“DWD can be boiled down to a core protocol where an application would broadcast a list of widget specifications, at which point other parts of the system (“DWD Consoles”) could take the specified widgets structure, generate the UI, and display native widgets where desired.”
What are the advantages of using DWD?
By using DWD, KDE would strike a balance between SSD and CSD, in which applications could have the flexibility to include their own buttons and contents on the very decoration part of the window –
hence, minimizing the space the App takes on the screen (a highly valuable feature when it comes laptops and smaller sized screen devices) and will also allow nicer, flexible layout.
While on the other side of the coin, all the control would still remain at the hands of the window manager, certain “compulsory” buttons would still draw and remain in their expected place thus preserving consistency in between Apps and other DEs.
This sounds super-cool but what are the drawbacks for this type of design?
You are absolutely right if you’re thinking nothing is perfect and there must be some cons coming along this design;
Questions have already started popping up, such as: “How do you move a window if everything in the title bar is interactive?” and for the most part are being mitigated by the designers and devs behind the idea. (by saving space between each separator to allow for drag area)
Of course the above is merely a general depiction of the idea, hopefully, there’s more to come and may it be implemented correctly and smoothly as possible :)
Source: Ken Vermette’s blog
