If you are a long time Plasma user, you probably remember the times when most GTK applications in KDE Plasma prior to 5.18 were practically unusable due to the lacking support for _GTK_FRAME_EXTENTS. In this blog post, I would like to get a bit technical and walk you through some changes that happened during the 5.18 time frame that made it possible to support _GTK_FRAME_EXTENTS in KWin. I also would like to explain why after so many years of resistance, we had finally added support for client-side decorations. So, buckle up your seat belt!
What is _GTK_FRAME_EXTENTS, anyway?
A window can be viewed as a thing that has some contents and a frame around it with a close button and so on. The “server-side decoration” term is used to refer to a window frame drawn by the window manager (KWin). If the application draws the window frame by itself, then we refer to that window frame as a “client-side decoration.”
A cool thing about client-side decorations is that they are very eye candy, but there is also a lot of drawbacks about them, for example if the application hangs, the user won’t be able to close the window by clicking the close button in the window frame. But the biggest issue with client-side decorations is that the window manager has to know the extents of the client-side drop shadow otherwise things such as window snapping and so on won’t work as desired.
_GTK_FRAME_EXTENTS is a proprietary GTK extension that describes the extents of the client-side decoration on each side (left, right, top, and bottom). From the word “proprietary” you have probably already guessed that _GTK_FRAME_EXTENTS is a thing that is not in any spec. We can’t afford implementing a proprietary extension simply because we don’t know whether re-designing KWin will pay off in the end. What if GTK ditches _GTK_FRAME_EXTENTS for something else and our hard work will be for nothing? There were some suggestions to standardize _GTK_FRAME_EXTENTS in the NETWM spec, but it didn’t go well.
So, what did change our minds?
It might come as a surprise, but the reason why we decided to add CSD support after so many years of being reluctant was Wayland. In order to fully implement the xdg-shell protocol (the de-facto protocol for creating desktop-style surfaces), we must support client-side decorated windows. Prior to that, we didn’t have any reason that could possibly somehow justify the changes that we would have to make in code that was battle-tested for many years.
With Wayland, we know what changes have to be done in order to add support for client-side decorated clients. Surprisingly, the geometry abstractions that we chose specifically for client-side decorated Wayland clients turned out to be also pretty good for client-side decorated X11 clients, so we decided to add support for _GTK_FRAME_EXTENTS since it didn’t require any huge changes.
It still means that we will be screwed if GTK switches to something completely different on X11, though. But let’s hope that it won’t happen.
CSD and KDE Plasma
“But Vlad,” you may say. “Does this mean that KDE is going to switch CSD?” No, as far as I know, nothing has changed, we still use server-side decorations. Support for client-side decorations was added because it’s something that we need on Wayland and to make GTK applications usable on X11.
Frame, buffer, and client geometry
Warning: This is a brain dump. Please skip to the next section if you’re not interested in technical stuff.
For an old school window manager such as KWin, client-side decorated windows are troublesome mainly because due to the long history all rendering related code had been written with the assumption that the window frame wraps the window contents. If an application draws the window frame on its own, that’s not the case.
In 5.18, we tackled that problem by introducing two new geometries to separate window management from rendering – the frame geometry and the buffer geometry.
The frame geometry describes a rectangle that bounds the window frame. It doesn’t matter whether the window is client-side decorated or server-side decorated. This kind of geometry is used practically for everything, for example window snapping, resizing, etc. KWin scripts see and operate on this geometry.
The buffer geometry is used primarily during rendering, for example to build window quads, etc.
In 5.20, we introduced yet another new geometry, which existed prior to that in an implicit form – the client geometry. The client geometry indicates where the window contents inside the window frame [1] is on the screen. We use this geometry primarily for configuring windows.
It can be a bit challenging to deal with three different geometries at the same time, but there is not that much we can do about it, unfortunately. Each geometry has its own specific domain where the other geometries are inappropriate to use.
Conclusion
CSD is a rather controversial subject in the KDE community, but it’s here and it’s not going anywhere, anytime soon.
[1] On X11, the client geometry actually corresponds to the geometry of the client window.
Wait – window drop shadows are a *client* effect, not a *compositor* effect?
How does that make any sense? Client-side decorations I can kind of understand, as some of the CSD arguments do have merit. I still think server-side makes more sense overall, but I can see how reasonable people can disagree there.
But window drop shadows? That’s a function of how windows from different applications are displayed relative to each other. How does it make any kind of sense for the clients to render those? That’s not their job. The windows might not even be being displayed in a “desktop” paradigm.
Imagine if they’re being displayed as part of an augmented reality VR system floating in space, and there’s a “drop-shadow” being projected…. onto what, exactly? There’s nothing behind the window for the drop-shadow to be projected on to. You’re just going to have a “shadow” floating in space.
I can see why adding support for that would be a long way down the priority list.
If the window manager draws the window frame, then the drop shadow is also drawn by the window manager.
On the other hand, if the application draws the window frame on its own, then it is also most likely responsible for drawing the drop shadow.
That just doesn’t feel right to me. It feels like the abstractions are in the wrong place.
But then, I’m not a toolkit/compositor author. I guess the people who are have looked at the trade-offs, and know what they’re doing better than I. Still, as a long-time user, it doesn’t match the model in my head of how windows should interact with each other and their environment.
You’ve just articulated one of the common criticisms of CSDs. 🙂 Turns out that the word “Decoration” encompasses quite a bit, and not just the window’s titlebar.
Thanks for the detailed explanation, Vlad!
As a long-time Plasma user I’ve followed the CSD/SSD debate over the last 10 years and have done so, with great technical understanding and interest. Since the beginning, I’ve been fiercely in the “server-side” camp and have seen the debate evolve over the last two years, where CSDs are being seen more positively and pro-SSD arguments increasingly being portrayed as more “radical viewpoints” by some. Given the passion this debate has been fueled with in the past, I can see this, yet it also worries me.
At the core of it, KDE and Plasma have always been about “doing it right” and therefore I can entirely see the point of implementing CSDs because of the simple fact that it is now a established requirement in the xdg-shell protocol. This effectively means we’re yielding ground on the basis of pragmatism and compliance and that we’re acting in the interest of our end users, and that last bit is most likely a good thing and something we can justify as being part of our core beliefs.
However, we must retroactively reflect why server-side decorations have been fought for in the first place, and that’s summed up roughly as “separation of concerns”, “security” and “consistency”. As a user, I don’t want to be using a inconsistent OS experience where apps can have widely different appearances and behavior, and the fact that all GTK apps can now render their own window frame, will sooner or later lead to apps that want to stand out and start customizing up till the point that its much more than just Chrome/Firefox being the odd ones. The adagium “if they can, they will”, is really going to apply here, of which the many “standing out” apps on Windows are solid proof to me – especially commercially developed Linux apps are going to fall victim to this and this is just a matter of time.
The concerns remain, and all that we know for sure now, is that Kwin is going to have a dual-stack implementation for the foreseeable future. To me this actually feels like a golden opportunity to turn this into a situation where we’re going to support SSDs and CSDs equally well, but *with* the opt-in possibility to put the end-user in the driving seat. What I’m getting at is to revive the earlier “xdg-decoration” protocol and put our full weight behind it in upstream conversations, including allowing end-users the ability to override the default behavior and to be able to force SSDs onto CSD-first applications. If necessary, a plugin to GTK can be considered – similar to that appindicator extension to GTK – which would turn off the window-frame rendering when the compositor announces a “forced server_side” mode.
I know this is easier said than done, but I do believe this “final compromise” is absolutely worth fighting for, since it would support CSDs out of the box but additionally allows power users and distributors who want a consistent user experience, to enable a “forced server_side” mode.
What this also would enable over time, is to revive the idea of dynamic controls as part of the server-side stack inside Kwin (DWDs). It doesn’t have to become too fancy, but applications gaining the basic ability to export a few controls over D-Bus – just like the task manager app menu items – and the compositor retaining the job of managing behavior and aesthetics, could become a opt-in killer-feature for end users since it addresses the concerns of security, consistency but also takes on the reasons why Gnome chose for CSDs in the first place: features/space saving. When it works well enough, it may be turned on by default after some time, depending on how much it would be adopted in popular GTK applications.
Just my two cents, a few more maybe..
Sounds like a fantastic idea. Can you help drive that forward?
I only noticed this a few weeks ago!
Now Firefox finally looks good when disabling window frames in firefox settings!!!
(and why is it not default?)
Thank you!