As a kind of Christmas present to our Wayland users I’m happy to announce that over the last two weeks I worked on adding support for server-side decorations.
The main motivations for working on it was the fact that I want to switch to Wayland as primary driver for my system and the nested KWin running on top of another Wayland server, which I need for development, doesn’t have any decorations. Of course I could have implemented client-side decorations for it. But as my readers might know, I consider client-side decorations as an inferior solution. And KWin of course has support for server-side decorations anyway for X11 and thus it’s less work to go for server-side decoration than to go for client-side.
The second reason is that Qt’s default client-side decorations are comparable ugly and lack important features like a difference between active and inactive windows which makes using a Wayland session really hard.
In this case a possibility could have been to develop a plugin so that KDecoration based themes could be used for client-side decoration. But to get it really useable this would have required a complex protocol to get in on par with what KWin internally has.
So here’s the solution:
A core element is a protocol to negotiate whether a window should have server-, client-side or no decoration which got added to KWayland. KWin got an implementation for that both as server and client. I plan to submit the protocol for inclusion in Wayland next year. I do think that this can be a general solution: KWin won’t stay the only Wayland compositor preferring to not have client-side decorations. If we think about tiling and use cases like phones we see that client-side cannot be the ultimate solution. Thus I think it’s a useful extension. Of course it doesn’t forbid client-side decoration, that’s still possible with the protocol. So GTK+ applications build upon client-side decoration are still able to use it, but of course I highly recommend to use server-side decorations on a system that prefers server-side decorations (the protocol is also able to tell that).
The last part to get this working got implemented in our Qt Platform Theme plugin for Plasma. This plugin will move from frameworksintegration to Plasma with 5.6, so we can easily extend it and depend on KWayland. The plugin checks whether the server supports the protocol and if it does it disables Qt’s client side decorations. For each new created Wayland window it tells KWin to either use server-side decoration or no decoration (popup windows). As all of that is implemented in our platform theme plugin it means that it doesn’t affect other Wayland compositors. There the plugin does not get loaded and Qt’s client-side decorations will be used. So no fear: this won’t affect GNOME Shell at all. As the plugin is currently in the process of being moved, it’s only in a scratch repository and won’t make it to main this year. Our code deserves a Christmas break as well 🙂
Happy holidays and a successful Wayland year 2016!
hm nice but screenshot is broken
sorry, fixed
I think submitting the negotiation protocol is really, really great. I was hoping for something like this in Wayland since they said that Wayland has CSD. Thank you so much for making it happen!
One question: who will have the last word on by who decoration is drawn? The client or the server?
In KWin’s implementation the client’s request is honored.
Will there be absolutely no way to tell kwin “No, I don’t want the client to draw its decoration, if it asks to, refuse anyway”?
This doesn’t work very well at the moment in X, I was hoping the switch to wayland and the redesign of this negociation would make things better.
We cannot force the client. It can put into it’s window whatever it wants. KWin doesn’t know what is in the window. So more than kindly ask is just not possible.
But kwin can keep its own decoration even if the client refuse to let its own go? Taht’s how I do it now. It’s ugly, but I rather have both that only the client side ones.
I was doing some reading earlier about how appmenu died, and I’m wondering what it would take for KDeocration to support a Notification / StatusNotifier like protocol to put menus in the titlebar. A lot of the hive mind around CSD is minimizing wasted space, and nobody should argue having about 1/16 a window’s physical space dedicated to just its name and a few buttons on either side wastes some real estate, especially when maximized, so I’m wondering if there is anything on the table to let applications put functionality in the title bar the way they do on pretty much every other OS nowadays. Preferably with a Wayland or Freedesktop standard rather than some arbitrary Canonical swill (Dave made a great post on the main forum about it here: https://forum.kde.org/viewtopic.php?f=285&t=125058#p329981).
It isn’t that big a deal, but if you are making a server side decoration proposal its something to at least wonder about, especially with plasma mobile probably wanting some functionality like that in case you have a global drawer of some kind outside the app. I know thats not anywhere on the radar now, but some vendor might want that kind of functionality some day, say for on a remote control with some kind of fixed mapped control scheme so the compositor can present some menu bar of options for the app globally, like on an LCD remote.
Have a look at https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/
Cool! Thanks for the link, never heard of DWD before, but it looks super promising. I’m going digging for more recent developments now.
Hi Martin,
I’ve read on his blog that he’s still working on the specification, do you have any plan to implement it when it’s done? Even if it’s only a KDE thing, it looks useful and I’d really like to use it with Connect.
Thanks, your work is always appreciated
Gnome apps already do something that looks like this, but I don’t know how it works under the hood. It looks great, even on KDE, though not as great as the mockups for DWD. Is there any way to make DWD Gnome compatible or work together with the Gnome guys to agree on a common specification? Nobody likes incompatible protocols for essentially the same thing.
Kudos and thank you so much for keeping up the good fight for Server-side decorations! 🙂
Hopefully this can be accepted (eventually) as a standard protocol for Wayland.
Great work dude!
wl-shell doesn’t have the notion of an active window like xdg-shell, I believe that is the reason why Qt default decoration doesn’t do that.
well, the window with keyboard focus is the active.
Indeed, the keyboard focus is enough. The reason is simply lack of time/interest in implementing the distinction.
It’s always a pleasure to read your articles !
I wonder, in Kwin/Wayland are shadows part of the decoration or drawn separately by the compositor ? Because one thing that bothers me actually is that client-side decorated applications (such as Steam or chromium) don’t have shadows in KWin/X11 while they do when using GNOME/mutter. Well, sorry if that’s offtopic.
Anyways thanks again for all the work you are doing in KWin and KDE/Plasma. I really can’t wait for the Wayland session to be stable enough for daily use.
Shadows are provided by the decoration but drawn separately by the compositor. Also client-side decorated windows can provide their own shadow to be rendered with the compositor. That’s how Plasma’s dialog windows get shadows.
I assume that Mutter adds a generic shadow to the windows. We don’t do that as we think that’s a bad idea. A shadow needs to follow the light model of the window and blend in. Thus it needs to be specified by the window.
Thank you very much! Forced CSDs were one of my major gripes with wayland and I’m happy to have an alternative.
To be clear, it was less about “forced CSD”, and more that they didn’t have a protocol for it.
The default is CSD, but that’s because CSD is the same as no decoration at all.
This is not a pissing match to see who’s most offended by the FREE WORK BEING DONE BY PEOPLE WHO DON’T OWE YOU ANYTHING.
Thanks a lot Martin. But what happened to Dynamic Window Decorations. I really liked idea.
Hi Martin, I am very happy to hear you are planning to submit another protocol extension for public consumption. I sincerely hope it doesn’t become another flamewar. From what you explained here and without seeing the actual spec, it sounds like a good idea to me. Still, I think Weston probably won’t implement support for SSD, not without some major rework, because we lack all capability to draw (rather than just composite) in the server as a design decision.
Sorry I haven’t had a chance to take part in the idle-extension discussion yet.
Keep the good work up!
I know I may be kind of beginner, but wouldn’t it be better (while using SSD) to allow widgets to draw over the decoration (but not above the buttons) and reserve a specific set of controls (e.g. left-, right-, middle-click, drag, or keyboard keys) while passing the rest to the server? (Although the client should be able to know where the buttons are and/or where it can draw and which space is prohibited)
Thus, if the client is not responding, only the area at which widgets are resident, and controls they have reserved are out of control then. Thus a button that did not reserve the dragging control won’t render the application non-movable even if it is hold using it, and if not, it was not supposed to be used move the window, anyway.
And if it was on mobile/notebook mode, the server passes an empty space that the client is free to draw inside.
This is what I was hoping for since I heard about CSD being the (temporary) default in Wayland as well, great work!
Could you post a link to the relevant repo so interested people can have a look?