When the first CSD “what if” was made in the KDE community forums it became the catalyst that got me in touch with some of the fine developers who really do make KDE happen, from them and members of the VDG I was educated on a new method of decorating windows with clean yet powerful widgets, and I have the privilege of presenting the idea we have worked and iterated on for some weeks now today;
Foreword
Client-Side Decorations (CSD) and Server-Side Decorations (SSD) are two methods for displaying the frames around our windows; and as history gets written it would be noted that KDE would back SSD, and Gnome would embrace CSD.
As a primer for those uninformed about what these two things are; lets begin by saying the window manager is the “server” and the applications are “clients”. “Server side decorations”, make the display server or window manager responsible for drawing the frame including window controls and title of the window. “Client side decorations” make the application is responsible for drawing its own frame. While the difference is subtle, the impact is notable; It historically determined whether or not applications could draw buttons or other widgets in their own windows, or even forego window frames entirely; usually saving a great deal of space in the process. But once an application is responsible for drawing its own frame, all sorts of naughty things can happen, such as a crashed application becoming immovable or unclosable – without opening task managers or using cryptic hotkeys. If programs don’t do the highest quality job drawing their decorations, it causes problems.
Because of those points, SSDs are traditionally considered inflexible and wasteful of space, while CSDs are considered potentially unstable and unpredictable in certain cases, but very flexible in general. KDE developers like Martin Gräßlin, and many other KDE contributors have given this topic serious thought because there are serious pros and cons on either side, and made the decision that CSDs have too many downsides they want to avoid.
Introducing DWD; the next generation of SSD
The VDG has been tasked and trusted by very intelligent folks to conceptualise an evolution of SSDs; internally we’ve been calling it Dynamic Window Decorations or “DWD” for short, to avoid confusion. And it has us excited.
Before I continue, a disclaimer:
This is still deep, deep in the conceptual phase and we don’t know *if* it will be implemented, when it would be implemented, how it would be implemented, or when it would be adopted. There’s a large number of ifs, and we don’t have specifics. One thing we will say is that currently, this is the idea with the most developer interest;
Also, we are actively seeking community feedback on the DWD concept, use-cases which might be desired, and developer feedback. I’m sure we’d also want feedback from other projects interested in the DWD concept.
Lastly, there’s many examples in this post; many developers are probably finding out about this concept the same time as you – please don’t inundate them with questions; we don’t know if this concept will even be implemented. KDE developers are extremely busy with many fantastic features, so please respect their inboxes.
Thank you.
So, what is DWD?
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. Using this method, DWDs try to strike a balance between SSDs and CSDs, allowing application developers to be more flexible inside the window decoration while also addressing the need of a window manager to remain in control to avoid the downsides of CSDs.
Indeed, DWDs would be themeable like traditional decorations, fully supporting transparency effects.
It’s important to note that the application is not responsible for drawing the widgets, only specifying what widgets it wants drawn. An application might say “I have a button, this is its text, and when its clicked I want it to send a signal back to me”. The application would have no part in the rendering of the widget.
What could DWD do for you?
DWD is more than being able to embed some widgets into a window border – that’s the main benefit and design goal, but we quickly realised it can go a lot further since the window manager could also relay these requests to other parts of the system; enabling them to become “DWD Consoles” and display widgets outside the window entirely;
- Plasma could display widgets directly on a panel, below window thumbnails, or even directly on the desktop itself, controlling windows without even opening them. Exporting windows controls to a plasma panel may allow some applications to run completely chromeless.
- A media player might export its most prominent controls, and you could use them in the task-manager window preview without ever restoring the window. (thought in some scenarios it’s also possible with MPRIS)
- Tools like the amazing KDE Connect could receive requests for controls and embed them on your phone. You could conceivably open your phone – in another room – and tell Muon to do an update and watch the progress from your phone.
- Finally, raw console. Not so much for usage as much as it would be used for testing the protocol in a bare-metal way.
DWDs could be exported to panels, window decorations, or potentially even phones.
What would DWD look like?
DWD in decorations would look remarkably like CSDs, but more consistent. Applications would not have the ability to say “I want my decos on the bottom”, or “I want my window frame to be pink and furry”, or “I want my window to be a trapezoid”. DWD applications could, however, provide a stripped-down version of the standard colour palette used by KDE which the DWD Receiver could optionally use, which the user could still optionally disable.
What is important to notice, however, is that as opposed to CSD, the window decorator remains in full control. If an applications asks the decorator to use a special color palette and the user doesn’t want that, the window decorator can decline the request and keep all applications visually consistent.
If you were the type of person who has a theme with their window controls on the bottom, you can rock bottom-window DWDs! Do you like your minimise button on the left, and your close button on the right? DWD can fit in the middle. A core goal is the acknowledgement that users know what’s best for themselves. You should be able to configure what you like, and have your preferences enforced by the system.
DWDs could export most – if not all – chrome in simple applications.
If a computer doesn’t have DWD – or you disable DWD, then DWD would simply fall back to drawing widgets inside the traditional application area as usual. So if you use Gnome, XFCE, Windows, or Ratpoison, DWD won’t break other environments. KDE apps would look and run almost exactly the same as they do now; when they open they would quickly negotiate with the DWD server to determine if they should hide some widgets from the content of the window and have the server render them in the DWD instead, always showing the widgets in the traditional content area if no DWD support was detected.
In addition, applications such as Mozilla Firefox could use plugins to export their tab data and hide native tabs – giving non-standard applications full DWD support. Since DWD would be standardised, any plugins of this manner would only need to be updated to support the application – and would work wherever DWDs are supported.
Distributions could potentially brand DWDs knowing they would not be violated by applications.
How might DWD work?
DWD is a protocol based on applications exporting the structure of a small set of widgets, along with a menu, and metadata such as colour schemes and technical info in a client<->server<->console relationship. This would be done in an environment independent manner, so DWD could function on any environment that wants to implement the protocol.
The specification would limit applications to exporting from a set of predefined widgets, and the control of how those widgets are used is entirely up to whatever is drawing those widgets. The protocol would be kept simple, clean, and goal-oriented, with less focus on specific widgets (“I want a slider”) and more focus on actions (“I want a range”). Applications could not invent new widgets, but new widgets and goals might be added to the specification later as the demand is noted.
Many services could accept DWD controls, and act as DWD consoles; the window manager could display CSD-like controls, Plasma could embed controls in a number of places, and KDE connect could receive content, too. DWD would not be a replacement for protocols like MPRIS, but for many applications DWD would help broadcast a wider range of controls to outside sources than normally feasible.
The two main componented of DWDs; the control menu, and the console client (here shown as a window decoration)
As the widgets are drawn by the ‘consoles’, the window manager can handle applications that are stuck as it does now, allowing the various consoles to much more gracefully disable them until the application becomes responsive or is forced closed; so none of the downsides of CSD crash-cases impact DWDs. The primary goal of DWD is for Dynamic Windows Decorations, and it should always be the first design goal, but DWD opens many other possibilities.
DWDs in various states and configurations. The second example illustrates DWDs in environments without DWD support. Window decorations could easily offer different modes to better accommodate screens; Example 3 is a compact variant. Window decorations could also side-load or bottom-load decorations on the window – it’s up to the user.
Where can I learn more?
I’m sure there will be several developers reigning hellfire in on the various mistakes this post probably has – so the comments section will probably become a good place. But I’d recommend avoiding flooding developers with DWD questions; you will likely see DWD posts come out on aggregators or social circles, and until we have a firm grasp of how this technology might form – we request your patience. Smart people with more influence will likely help change these designs dramatically for the better if they go forward.
I will be posting more in-depth designs and work on individual components of this DWD concept, and refinement will happen as feedback rolls in. I, personally, will not post any more technical details on how DWD may work – I’m not qualified to go deeper on this subject, and again, smarter people will figure it out better than my conclusions; I’ll continue posting designs and concepts for DWD applications as a mini-series in the coming week, with more focus on individual DWD elements and application.
And again;
This is still deep, deep in the conceptual phase and we don’t know *if* it will be implemented, when it would be implemented, how it would be implemented, or when it would be adopted. There’s a large number of ifs, and we don’t have specifics. One thing we will say is that currently, this is the idea with the most developer interest.
Also, we are actively seeking community feedback on the DWD concept, use-cases which might be desired, and developer feedback. I’m sure we’d also want feedback from other projects interested in the DWD concept.
Lastly, there’s many examples in this post; many developers are probably finding out about this concept the same time as you – please don’t inundate them with questions, as, again, we don’t know if this concept will even be implemented. KDE developers are extremely busy with many fantastic features, so please respect their inboxes.
Thank you.
Last, but not least;
I’d like to give my sincerest gratitude to the KDE community for the support of my initial PlanetKDE posts, and especially to the excellent KDE VDG group whom I’ve had the privilege to work with. They absolutely define great community. I’m so excited to have gotten to bring the earliest VDG DWD concepts to the community, and the Visual Design Group was simply amazing in making it happen, so thank you!