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".
Cody continues:
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 😉
Window-as-a-document/object
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
Like your last blog post, I must agree completely.
The last thing I want to see is this:
http://www.netdummy.net/images/tune-up.jpg
http://cybernetnews.com/wp-content/uploads/2006/03/MicrosoftOffice2007.jpg
http://www.instructables.com/image/FVQNF3RF1L8W0PC/How-to-create-your-own-command-prompt-in-windows-x.jpg
I should have know not to click on those links 😉
Thanks for providing so much detail on the topic. You should blog about KWin more often 😉
You missed one point: The configure-central argument is void if the windowing manager cares about the decoration and the clients run on different machines. This will never work if every client has to be configured individually (and changed all the time depending on which desktop shows its windows).
Thanks, that’s a good point. As I always use just my local client windows, I did not think of it
I agree with most you say except 1 thing:
“Proper way to do tabs in titlebar, a-la Google Chrome”
This ,at least in current kwin, it’s a bit difficult because apps can’t really know if they are in a group or they can’t open a new window in it’s tab group.
I saw rekonq mailing list discussing this a while ago. This is the article:
http://www.mail-archive.com/rekonq@kde.org/msg01080.html
But if this was sorted out, and windicators were provided as a dbus api and the icons drawn by the window manager (this isn’t reaaally difficult is it?) I really think window manager is the way to go.
Yes KWin currently does not support application integration for window tabs. This is (for me) a must have and on my TODO list for 4.6. I will implement it with rekonq as I think it will be the application which would benefit most of it.
Applications as tabs would be outstanding! And it will make a lot of sense for netbooks especially instead of using a global menu thingy (like Canonical is going to adopt for netbooks).
Not sure if you’re talking about this or letting the window manager take care of multiple instances of the application while deprecating the application’s tab, for a better (window/application) management.
i agree with you in most of the points you mentioned.
But if you want to be taken seriously, change your tone. Sentences like “When I was reading this I got such an laugh-flash that my roommate was asking what happened.” or “Is that really the level of argumentation? That sounds like someone did not find arguments.” are unnecessary and prevent a productive disussion from happening.
Sorry yes, the tone is somewhat not appropriate, which is a direct response to the tone of the blog post on planet gnome.
From what I care, it’s all good. There are other choices besides GTK and Gnome.
I use Gnome/Ubuntu, but I would be rather happy if Gnome/GTK+ just rolled over and died and people looked into KDE and such (yeah, I know this won’t happen).
So if Canonical wants to risk it and *maybe* come up with something better, be my guest.
So basically what you’re saying is that the behavior of windows in a window manager is dependent on how the window manager interacts with the decorations, which are a nice link between the window and the window manager. Decorationless windows (or at least windows that don’t use decorations from the window decorator) are thus not really meant to be manipulated by the window manager because they don’t or even can’t implement that link entirely correctly if they do at all. Client side decorations are doomed to play catch-up with what is defined as the correct interaction with the window manager. Am I understanding this right?
This is spot on. Client-side window decorations are just a bad idea all-round and they break a working system for no good reason. (As you say, anything that can be done with client-side decorations can be done better with a good(!) window manager and a little dbus integration.)
Now that were some convincing arguments with a good deal of insight! Keep up the great work on KWin, it’s the best window manager I’ve ever used.
Here is a follow up by Shuttleworth on the topic:
https://wiki.ubuntu.com/MeetingLogs/openweekLucid/AskMark
I copy here the relevant part:
[16:27] QUESTION: Will Kubuntu/KDE have windicators, or will that be a Gnome only feature?
[16:27] i hope they do
[16:27] it will be straightforward to add to KWin if the maintainers see fit
[16:27] and we’d likely add it in Kubuntu
[16:27] so a Gnome app running on Kubuntu feels at home
[16:28] of course, then the menu would be rendered *properly*,with Qt 🙂
[16:28] in my blog, i said that the work was enabled by CSD, which is incorrect
[16:28] it was inspired by CSD – it was thinking about CSD that inspired the idea to give that space back to the applications
[16:28] the actual implementation can be done via CSD or via the window manager
[16:29] and in fact, we *need* to express the windicators on the d-bus, to support the global menu case
[16:29] which is what the window managers could tap into
One reason why i really prefer window managers arefor buggy applications. Sometimes i endlessly try to close an app in windows and it just dies not respond (hung?). But with KWin if the app does not respond, i get a dialog allowing me to kill the app.
In the same blog post, in the comment section:
“Michael Hall says: (permalink)
May 3rd, 2010 at 7:51 pm
Rather than integrating windicators in a client-side window decoration, how about providing the information to DBus the way other indicators do. That way Metacity/Compiz can decide to use them as windicators, or the task list in gnome-panel, or cairo-dock, or awn, or whatever can decide to use them like the Windows7 “Jump List”.
Mark Shuttleworth: Yes, you’re right, that’s the right approach. I wasn’t clear, CSD provided the *inspiration* for giving that space back to the application, but this should be supportable with standard themes and window managers that watch d-bus.”
http://www.markshuttleworth.com/archives/333#comment-327213
“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.”
It’s not that I communicated directly with these corporations. I just opened a bug report in Bugzilla with an experimental patch, and since then I have been approached by various people who had interest in it. People from various companies, as you say, and various people from within GNOME.
Sure, I never approached the KDE community about it directly. And I didn’t approach the overall GNOME community directly about it, except by filing that patch in Bugzilla. But that’s mostly because this started out as just a little experiment.
“I just oppose that it is now another (false) reason why we need client-side-window-decorations.”
It’s not a false reason why we need client-side-decorations, it’s not a reason at all. It’s just an idea that Mark is floating around. Mark is really interested in thinking outside the box and experimenting, and that’s all I was trying to do with this initial decorations idea.
Anyway, I’m sorry you’re upset by this.. I’m truly not trying to cause you any grief. 🙂
But I hope you see what harm your “experiment” might do. Just think of Canonical pushing this to all users without resolving all the issues I have mentioned. It is in fact only a small list – several people mentioned more issues which are impossible to resolve 🙁
Thinking the other way around, I think a better implementation for such stuff (windicators, chrome’s tabs and some other interferences on windeco) would be the wm to be one piece of panel, having the windeco and window content as just one whole thing that takes widgets on top of it.
This way, the window manager could provide consistent behaviour and look and apps could place widgets wherever they want, but common stuff would stay at their common places: (as titlebar concept doesn’t exist in this approach) window title, icon, max, min and close buttons (and whatever else) would always go where defined in settings (center, left, …). Colorize window border would be an option (which would lead to regular old titlebar look). Then, if one wants to implement windicators at the right side, next to the icon or who knows, they would (taking space from title’s maximum possible width).
Also, space not used by widgets would have the same behaviour of what we have only on titlebar, as on windows and mac (and almost done in ubuntu — only on menubar, and not totally done), where you can drag the window, context-menu it and so on.
All that would bring consistent look and behaviour, allow apps to use some more space if wanted, and also update kwin’s concept of window to current one from both market share leaders OSs (not to just mimic but thinking on what users are experiencing from now on as window).
What do you think?
Actually, better than allow to colorize window borders is to let it to the theme. If the author wants to make it look like KDE <= 3 windows, with windeco images and colors on the background for those parts of the window, let him! If not, it looks like one piece! 😉
Yes, such things belong into the window manager. That’s exactly the point of my blog post 😉
And what about implementing it. Do you think this is feasible?
If so, we could get this for kwin and suggest the implementation for Canonical/Ubuntu for Metacity/GTK+.
Also, we could get it in a way so that kde and gnome apps would have no trouble with each other’s apps.
Actually, BTW, great time for it, I guess, once gnome 3.x is comming!
if someone comes and implements it: sure. i don’t have time for it and i don’t think other kwin devs have time for it.
I don’t have time to go reading all the comments on everyone’s blogs, so I’m not familiar with the complete list you’re referring to. If it’s important to you, please summarize it and send me an email.
In fact if you were really serious about this entire anti-csd rant, you probably should have just emailed me directly to begin with. I don’t quite understand the point of complaining about someone else’s work on your own blog. 🙂
I will do that, but will wait till next week after our feature freeze as the list will be somewhat long. Basically I will go through all kwin features where I think it is impossible that this still works with client side window decorations. Honestly, I think that are all. Btw I already mentioned my most important concerns to you on IRC.
I do not rant about your work, but about the concept. And I did that on my blog because I wanted to make other developers aware of the broken concept. We see lot’s of praise to client-side-window-decorations on some blog posts (including Mark’s) and so it’s just the right thing to discuss it on blogs. It’s also common to discuss such issues on planetkde. It’s a kind of communication channel and to be honest I did not know who is responsible for this idea. Due to Mark’s blog post I thought it is completely Canonical’s idea and they have a history of ignoring concerns coming from the KDE community. So blogging and raising awareness was the right thing to do for me, especially given that no discussion about if someone actually wants client-side-window-decorations has been started. I think this is the right start to discuss it, before we have a utterly broken setup in Ubuntu 10.10!
After reading supposingly all the arguments from both sides it seems to me that you have not noticed the most important one among them – the main target of Mark’s blogpost was not to push CSD to upstream, but to introcuce windicators as the are.
As it was shown at least in 2 posts above, windicators can be implemented not only with CSD, but also using dbus mechanism leaving all the painting to window manager, so most part of the fight CDS vs window manager migh be ommited if we talk only about windicators. And as it was shown in same above comments, Mark also agreed with such solution, so Canonical is not going to bring evil CSD because they can – they just want to implement their windicator concept in the best way they will find. So can you comment on this particular argument? Can that be a point from which the discussion could move from emotional to constructive phase?
it’s plain simple: you don’t need csd for windicators. so we should have a look on why we need csd. what are the benefits, what the disadvantages. up to now i have an empty advantages count and a very long disadvantages.
I saw some GNOME guy spoke about “”zooming” when going to fullscreen” and you speaking about how you can do it in half an hour… Can you actually do it for 4.5? It would be über-cool! And while you are at it, enable it also for maximizing apps! 😉
no, cannot do it for 4.5 as we are in feature freeze
I don’t really get it.
So you animate stretching the window to full screen, then ask the window to repaint a new layout for the new geometry? That’s just replacing one discontinuity with another one. And I’d argue that the new one while maybe being a “smaller” discontinuity (by some measure) will likely also be weirder and so more jarring.
If your app is all plasma-ish or clutter-ish (or otherwise animated-canvas-ish) you could probably ask it to do something amazing.
Or you could blend between the original and redrawn states while animating the resizing.
But for what? Maybe it’s worth it to look funky but it is certainly no reason to mess with the architecture of the Window Manager (ie introduce client-side-decorations) even if it were required.
just a small point. I like the concept of wayland and wish it good luck.
Part of it is because the developer is not an idiot and in fact wayland does *not* require CSD. there will be a compositing+windowing manager (currently implemented as a plugin). It will have all the windows already rendered in glxpixmaps and draw them inside decorations, tear free.
Saying that wayland requires or even suggests using CSD is absurd in my opinion.
thanks for the info, that’s very important to know.