So finally I know who had the idea of client side decorations: it’s Canonical. Why didn’t I think of it before? I have been aware of the fact that GTK wants to do client-side window decorations since it was mentioned on the EWMH mailinglist and I think it is a completely stupid idea which has the potential to destroy one of the most important advantages of the free desktop: a consistent client handling.
For those who don’t know what client-side window decorations are: the window client, that is the application draws the titlebar instead of the window manager as we have it today. I will discuss the disadvantages of this approach later in the post.
Up to today I have not found any valid reason why you should even think of client-side window decorations. Well Mark provides a reason: windicators. A kind of Statusnotifier inside the application. As the window decoration cannot do it (today) it is the logical consequence to remove decorations. It would not have been possible to extend an existing framework.
Well to be honest we get request to add arbitrary functionality like a mute button in the decoration about once a month. And we always say no, because it is not possible as there is no common interface. With something like a dbus protocol these "windicators" would be possible, not that I’d think it’s a good idea.
But apparently Canonical did not think of extending the existing functionality, but to remove the functionality. There is already one application which uses those client-side-decorations and it’s called Chromium. If you want to have an impression on the consequences of client-side decorations, just go through all open KWin bugs and look for the mentioned applications. I think you will know which one is currently my most loved application from a wm-dev perspective.
So what will we lose due to client-side decorations?
- Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application
- Window Tabbing (KWin specific)
- Window rules like always show a close button even if the window is not closeable
- Accessibility features like big border and button sizes for all windows
- Easily changeable window themes
- Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window)
In general up to now I always read of the same advantages, like it saves space. But that is just not true. The KDE Plasma Netbook Shell illustrates in a perfect way how we can use space more efficient. I also have some ideas for Aurorae like decorations on the left/right (implemented) and autohiding decorations for maximized windows (due to upcoming feature freeze probably 4.6). Also I think that Rekonq is a nice example to show how we can use the limited vertical space in a well thought way. Yes I agree that statusbars are somewhat useless and outdated, but just look on Rekonq’s clever behavior for statusbars. Or think of KDevelop’s (congrats to the release, I love your application) usage of the empty space next to the menu bar. Of course we have some problems of space wasting, but that is no reason to break with working solutions.
To summarize: client-side-decorations will destroy more than they benefit. Please devs at Canonical, please think of the consequences. Please think about the fact that you have to change all applications, please think about that your Upstreams might not like the idea, please think about more than one or two years. Please have a look on the Microsoft Windows platform and the totally inconsistent window behavior. Think about how the free desktop could look like if we start to use client-side decorations allowing each program to enlighten us with their preferred idea of window management. If we get client side decorations, Mac OS will be the last useful system with a consistent behavior and I think we can agree that this is not a nice few. Please remember that a window manager is called a manager, because he manages the windows. I do not like to see mistakes fixed ten years ago in the window managers to be present again (what about a drag delay in moving windows on free space in the new Ubuntu GTK theme?).
As far as I followed the small discussion on the EWMH specific mailinglist, the idea is that the window manager has to announce that client-side-decorations are allowed. This means that we as KDE have the option to not implement this "feature" so that our desktop will still have a consistent user experience. It’s also our chance to raise the concerns again when it is discussed on the mailinglist in more detail (which has not happened, there has not been any discussion, if we want client side decorations or not). Given that Metacity is developing a new theme engine, I hope that also the GNOME community opposes such ideas.
I also hope that Canonical will start to discuss such ideas with their upstreams. There has been no discussion about NotifyOSD and their removal of actions. With the "Panel Indicators" I though that Canonical mastered this part of their history and starts to collaborate. Now it looks like alea iacta est again, without any chances for the upstream to raise concerns
Powered by Blogilo