As there has been quite some reactions on my recent blog post explaining why client-side-window-decorations are a bad idea I decided to answer some of the comment in a new blog post.
First of all I want to say that Canonicals idea for windicators is not the reason why I dislike the idea of client-side-window-decorations. I am afraid of this development for quite some time and wanted to write a blog post on that issue for quite some time. German readers of this blog post might have noticed that the current issue of freiesMagazin contains an article I wrote in March on that topic. The fact that it was published almost the same time as Mark’s windicator announcement is a lucky coincidence. So windicators are just the catalyst for writing the blog post. While I don’t think their idea is a good one (in fact I wanted to announce Plasmoid support in Aurorae as an April fools article) I do not oppose the development in general. I just oppose that it is now another (false) reason why we need client-side-window-decorations. Yes it is possible to implement something like that in the current KWin decoration API and I think our recently added support for window tabbing should be proof enough that window decorations can be extended.
In my blog post I mentioned that client-side-window-decorations will destroy consistency. Apparently many readers thought I mean visual consistency. While this is an issue I don’t expect fixable (if it were fixable, why is my Mozilla Firefox looking different to all other apps?), it is not what I meant. I am afraid of the much worse behavioral inconsistency. Just try using Chromium in Ubuntu Lucid and you will know what I mean. The obvious counter-argument to that concern is that the Qt and GTK style will be patched so that all apps will share the same decoration. But will this work? I doubt it. What about all my legacy, proprietary applications I just cannot patch? They will have the window manager decorations. What about applications the authors don’t want you to patch because it’s destroying their brand? This is a real concern and to me the consistency in behavior is more important than visual glitches or a little bit more space due to removing the status bar. What I also want to note is, that KWin has many more features regarding decorations than e.g. Metacity. This is I am afraid that GTK+ decorations will at maximum gain feature comparity with Metacity.
Cody Russel commented and said that we just should relax:
Settle down, people. This is just an experiment, and if it turns out that it doesn’t work well or doesn’t gain us anything then we just won’t use it.
Now Cody, I have to disagree. Now it’s the time to raise the concerns. Canonical is starting to build up a new functionality on it. If we do not make clear that client-side-window-decorations are a bad idea this "experiment" will be in 10.10. Canonical has unfortunately a history of ignoring all concerns and shipping their utterly broken concepts and trying to upstream their strange changes (just remember replacing the suspend notification by a nag-screen). Sorry that I do not buy your "it’s just an experiment".
The reality is that client-side decorations is something I proposed, and there has been interest in it from Intel, Red Hat, Google, and now Canonical. I’ve even mentioned it to someone at Nokia once and he seemed at least interested in it.
It’s nice that you talked to all those corporations. Apparently you failed to communicate with the KDE, Compiz (and GNOME?) community. The fact that these corporations are interested does not turn the feature into a good idea. Sorry, I couldn’t care less to which corporation you talked.
I honestly don’t think this is going to affect you in any way. If you’re running KWin or whatever, and you run a GTK+ application under it.. just don’t run a theme that enables client-side-decorations if you’re concerned about how it’s going to fit into your environment.
This is a nice one. Is this a promise that I will never get a bugreport because an app seems to be broken because of client-side-window-decorations? Does that mean that I can reassign each bug to you? I do not just think of me, I’m thinking of my whole userbase and also of GNOME’s userbase. And introducing client-side-window-decorations is calling for trouble. Just an example we have with Chromium: since KDE SC 4.4 we unmaximize a window when it is moved. KWin has a drag delay, Chromium doesn’t. So clicking anywhere in the decoration area will unmaximize the window. This is an application bug, the developers don’t want to fix. You see, I have valid concerns to such ideas.
Now on planet GNOME there was one direct reaction to my blog post trying to invalidate each of my arguments. I spare you the details by just pointing out one of the "it’s not true" points:
Window rules like always show a close button even if the window is not closeable: Working around broken apps? Fix your apps…
Is that really the level of argumentation? That sounds like someone did not find arguments. But I understand: Metacity does not provide window rules, so you are not able to see the advantage in features you don’t know. As mentioned above with the Chromium bug: sometimes bugs are not fixable, especially if it is your legacy proprietary application.
The blog post contains some more "reasons" why we need client-side-window-decorations.
Tear-free window resizing (when the client is doing the resizing, with a proper resize grip for example)
I have tear-free resizing and Oxygen can provide a proper resize grip. Even if it were not possible: shouldn’t we fix the window manager? *scnr*
Better integration of resizing within applications (say "zooming" when going to fullscreen
Erm right, never noticed this missing usecase. Takes me half an hour to implement that as an effect which will be fast and not slow due to constant resizing of the window content.
Proper way to do tabs in titlebar, a-la Google Chrome
A right, that’s why KWin has window tabbing 😉
Why do we need client-side-window-decorations for that?
The best thing in this blog post was the link to the GNOME Wiki where we can find all the real arguments.
- Fix issues we get with non-reparenting WMs like compiz that transform the window and the user can see an ugly polygon edges between titlebar and app
When I was reading this I got such an laugh-flash that my roommate was asking what happened. First of all you should fix your apps™, second you should do your homework: Compiz will be a reparenting window manager in the next release. So reason number one is invalid.
- Have a good reason to push for rgba windows 🙂
WTF? Honestly? You want to break all applications just to get rgba? I know Metacity does not support RGBA in the decoration, so fix it™. The way KWin added support for RGBA should work for Metacity as well. We even added a new EWMH hint so that the window can request that the decoration paints the background, if you want a translucent theme.
- Possible performance improvement in reparenting WMs where there is currently a mismatch between client/decoration visuals?
So you are not sure if it will provide improvements? If you go the KWin way it should be fine
- single source for theming the application and decoration
Yes would be nice to have and exists. It’s called QtCurve
- Get gtk+ working on Wayland
Wayland? Come on, get real arguments. We can talk about that in erm let’s say ten years?
So that’s it. There are not more arguments pro client-side-window-decorations. So I read through all these documentations and arguments and to quote Faust:
Da steh ich nun, ich armer Tor!
Und bin so klug als wie zuvor
I still do not see any reason why we should break with a concept which has worked properly in the last 20 years or even longer. Why replace something working with something which cannot work, which will cause many, many problems. I am looking forward to a discussion on these issues. I just hope we won’t find it in the next Ubuntu release and all users have to suffer from a misconception during the design phase.
Powered by Blogilo