Quite regularly we see bug reports or user support questions about why KWin does not add its shadows to client side decorated windows such as GTK’s header bars. As this topic comes up so often I think it’s time to write a blog post to explain the situation.
First of all: this is a big misunderstanding. KWin does not have any shadows. KWin does not add shadows to any windows at all. There is no such thing as a generic shadow which KWin would add. Due to that of course KWin cannot add shadows to client side decorated windows.
Instead KWin provides a shadow rendering service. The windows can specify a shadow which will be rendered by KWin. This was created for Plasma’s windows which are after all also client side decorated. But is also used by the widget style Breeze and Oxygen for popup menus, etc. The protocol for the shadow rendering is available for X11 and Wayland. Also our window decoration API provides a possibility to set the shadow and inside KWin shadows are rendered using the same code path, no matter whether it’s provided through X11, Wayland or the window decoration.
The approach we chose here works really well for non-composited and composited setups. It also works well with other window managers and compositors as applications can easily check whether it’s supported and adjust rendering or just not provide the shadow. Thus a good experience is kept. Also the control over the design of the shadow is completely with the window and not enforced by the window manager. We noticed that enforcing by the window manager doesn’t work as the window manager has no idea how the light model of the window looks like. Does it require drop shadows, or is there a central top light requiring something like a glow? We don’t know only the application can know.
So if you wonder why a window is not having shadows it’s due to them not providing one. Not because KWin is evil and doesn’t add it’s shadow to it. We would be very happy to add the shadows if applications allow us to hook in. E.g. GTK could provide a plugin infrastructure so that we can add the shadows using our mechanism. We don’t expect GTK to add support for our shadow service – that’s too much asked for, though would be great. Instead all we need is a hook that allows us to add a plugin. That’s how we can do it in Qt (Qt Platform Theme plugin, QStyle plugins).
This is sad. It is like a tug of war:
+ KWin has custom protocol for shadows, and wants GTK to add support for it (either directly or through plugin hook like this post stated), which probably won’t happen.
+ GTK has _GTK_FRAME_EXTENTS, and wants KWin to support it, which also probably won’t happen.
Users have been suffering 4+ years due to this “no one wants to support the other’s custom technology”.
My point is, if GTK devs don’t care, then would it be better if we are the one who cares?
We cannot support GTK_FRAME_EXTENTS. Gtk devs are very well aware that it breaks assumptions in KWin.
What are these assumptions? Why Breeze can’t set shadows on gtk windows as for other kde windows?
Regards
Gianluca
“works really well for non-composited and composited”
Why do you care about non-composited setups?
“works well with other window managers”
Why do you care about other window managers?
“the control over the design of the shadow is completely with the window”
Why do you want it controlled by the window?
“window manager has no idea how the light model of the window looks like”
What light model? The window is just a rectangle.
I haven’t worked on KDE or kwin, but to me as an outsider it looks like the problem is with unnecessarily complicated requirements. Make it simple: hey kwin, here is a set of rectangular textures, render them with shadows. That’s it; very simple; no need for complicated protocols. Of course there are very few exceptions, like a very transparent window that wouldn’t need a shadow, but those are the ones that should use the protocol to tell kwin to skip the shadow.