After a seeming eternity the unthinkable has finally happened; DWD has been discussed formally on an implementation level and it’s exciting to say that some parts are now under development. Thanks to the CERN Sprint we’ve had Martin Gräßlin, Sebastian Kügler, a couple others, and myself in one room able to make final decisions on how it will all come together.
Dare I say DWD is officially real, entering development, and coming? Yes!
Previously I’ve made two posts about DWD concepts, this post will summarize the basics of DWD as it has been finalized. Some parts of both designs previously posted have been used and I’ll make another post later including mockups with more detailed information, but for new here’s an overview of DWD basics;
Low-Level IPC
DWD will use D-Bus as its IPC, being implemented via the KWin Window Metadata Tier 1 Framework. This is for Qt/KDE driven implementations, but anyone can implement DWD via D-Bus.
Core Structure
At its core DWD will work with ‘Semantic Objects’ and ‘Priority Groups’. Semantic objects refer to things like ‘media player controls’, ‘navigation’, and ‘actions’. Applications bundle Semantic Objects into Priority Groups, then push those groups to the window manager.
The window manager will tell the app whether a group was accepted or rejected; a group is rejected if any single semantic object in that group is denied for any reason. Higher priority groups get first swing at embedding their controls, and it may affect widget placement in certain situations, such as phone controls.
From there applications just hide their own elements in response to what groups were accepted. There will be some events and flags as well, but we won’t get into that yet.
Customisation
One aspect to note is that DWD will offer no customisation on the client-side. I had gone down that rabbit-hole in an early draft and we all deemed it overcomplicated. Ultimately what applications need to know is that the controls are being served – not how or where they’ve been served.
One thing we did was look at is Gnome CSDs which offered all the craziness applications could possibly want, and we noticed they weren’t actually being all that crazy with it. Generally the same controls made repeat appearances and when it really comes down to it in practice there’s not much of a value in extreme customisation. As we said previously if you need extreme customisation and weirdness this may not be the method for you – which is fine. At the same time we would recommend application authors examine why they would need exotic controls, and why they specifically need them in the windeco.
Stewarding the Protocol
One thing that was discussed was who and how to steward the protocol. When I first posted about DWD there was backlash about KDE being a ‘protocol gatekeeper’. Afterwards I proposed an extension-based design which also had backlash because it could make the protocol technologically ‘complex and messy’.
Ultimately we decided to steward the protocol and simply work with anyone who wants to be included in the design process directly. We will accept input into where the protocol will go and provide any resources we can.
One thing that was made clear was that some groups are uninterested in considering the DWD approach after being asked. We all agreed it’s not worth making a convoluted extension system just to cater to groups which probably won’t participate, instead focusing on making the best protocol we can for those who want DWD. For those environments that will not support DWD I’m glad to say that it’s still 100% compatible and applications using it will continue to work as normal, they just won’t have content in the decoration. We will not be breaking other environments.
Again, we’ll be open and welcoming to anyone who wants to join us in working on and implementing DWD.
The Implementation Plan
Right now early work is being done on our existing frameworks to move them into position to implement DWDs. Once that is done we’ll implement the protocol with a minimal number of Semantic Objects, and using the low-level API port a small number of simple applications as a beta. Applications being considered for initial DWD tests include Konsole, Kate, KCalc, and similarly small apps with basic requirements.
After the API has proven itself on smaller-scale applications we would move up to heavier applications. KDevelop was mentioned specifically as a candidate as its relatively heavy UI could benefit from space-saving DWDs while developers could very quickly give us high-quality feedback. This may be where we move to higher-level classes which will hide away the group/object system as well.
Designs & Reference Material Incoming
I’ll be making another post later with designs which should be mostly accurate to what the final protocol will produce; accurate enough to place in the Wiki as design references for how applications should look when using the final DWDs.
While Martin will continue focusing down Wayland and making excellent progress, he also had a rough timeline for when we can expect basic DWDs make an appearance. I won’t quote him as it was an off-the-cuff estimate, but it’s exciting to know there’s light at the end of the tunnel, and that we’re out of the conceptual phase.
On a complete aside it was a complete pleasure meeting everyone. Great to see some of the friends I met last year again, fantastic to make many more new ones, and I wanted to thank everyone in the Sprint as well as those who supported it for making such a great event happen.
Special thanks to CERN for hosting this Sprint! Be awesome and support future Sprints by clicking the links below;
Via Paypal for one-time donations
Become an ongoing contributor and official supporting member
Ken Vermette 
Hi,
I am excited about this topic! However, is there still drive to imolemting this in the near future?
Cheers,
Christian
LikeLike
Would it be possible for the Application to set a background image? Firefox does it but on Linux it doesn’t get applied to the title bar.
LikeLike
Hi,
really cool to see the idea become real 🙂
Do you still plan to use external protocols like mpris for the actual information-exchange? Or is dropping that what you meant by not being plugin-based?
I very much hope the former, because that concept seems so beautiful to me. Quite alot of the integration ideas you mentioned don’t intend to replace the actual controls in the application, so it’d feel wrong to use the DWD protocol for it, no?
LikeLike
Yes! We still plan on using existing D-Bus protocols wherever possible, including MPRIS. The discussion about not being extension-based is mostly about keeping our implementations of those protocols more consistent.
The goal of DWD is still to replace the actual controls and have window decorations take over them, so exporting DWD MPRIS controls would hide the native controls. There’s no reason why we can’t hit 3 birds with one stone. 😉
LikeLike
Why not let the client ask for space in the title bar, then let it render into (and take input from) that space like just another window surface? With alpha blending so the unused part looks like regular title bar. When available space grows, tell the client, let it maybe resize itself. When available space shrinks, tell the client, let it resize itself or face “eviction” from the title bar. This seems to be the simplest thing that could possibly work.
A possible argument against is that getting the client to draw in a matching way is more complicated than implementing controls in the compositor. It’s possible but I doubt it.
LikeLike
A core aspect we want to have is that the application doesn’t know how the controls are rendered. It might be in the decoration or in the task bar or only through kdeconnect. That might even switch dynamically (e.g. you maximize a window and the controls go from decoration to Plasma panel). To achieve such a level of integration the application may not have control over the rendering. This is really important. Otherwise we just end with Client-Side-Decorations done worse.
LikeLike
To add to what Martin said, if a window decoration has a really unique style it can potentially draw its widgets in that unique style in ways applications might not anticipate. Applications might be drawing rectangles with rounded corners but the ‘Ghost’ decoration might want its signature notches taken out of the input box instead. The “Google” and Material Plasma themes might want an input to appear as a simple underline instead of a box. Some window decorations may want to display content on a side, which applications may not understand how to draw, and it may be used in a panel – which uses a unique style entirely which applications may not anticipate.
Additionally, since we are taking a semantic approach we can begin to integrate DWDs more deeply into the desktop. This could go as far as integrating an upcoming ‘progress’ object into the lock screen so users could lock their computers and still see things like downloads working.
Lastly, we don’t have to limit ourselves to the window decorations this way. We can embed controls onto lock-screens, KDEConnect-enabled phones, widgets, and even other applications. One idea that came up was having KCMs use a ‘search’ object, allowing KSystemSettings to simply consume that search and fold it into the UI in a natural way.
There’s a huge number of super-exciting things we can do wit this technique, and hopefully it will all come out when I begin posting design targets. We strongly feel that these features done right can be far more valuable than taking the fastest route to drawing in decorations, and can make applications much more deeply integrate into the desktop in a variety of meaningful ways.
Hope that helps!
LikeLike
I see. I was assuming that the goal was to get most of the benefits of CSD without most of the downsides (non-uniform decorations and frozen apps being hard to kill / move / minimize etc) with minimal implementation effort.
The thing you mention sounds a bit like an extended version of tray items that can be integrated in many different contexts.
LikeLike