Tuesday, 4 May 2010

Client-Side Window Decorations and misconceptions

This morning, my RSS reader was full of news with links to Mark Shuttleworth's blog about Canonical's idea for windicators.

The problem now is people conflating Canonical's own design decisions (most of which I don't agree with, except for the case of netbook UIs, but that's not the point here) and Client-Side Window Decorations support.

Martin Gräßlin's blog lists a few things that you would lose if we were to use client-side window decorations. Most of them are just wrong:

Consistent behavior between all applications no matter if it is a Qt or a GTK or $Toolkit application: How can you say that when there's no agreements on the implementation yet? Of course Athena widget apps will look different, they already do. As long as the theming and behaviour is known and agreed upon, there's no reasons why it should happen. It's just a bit more complicated because you would have cases where the Window Manager would behave differently from the toolkit. All those are solvable, and old, unmaintained toolkits will not integrate.

Window Tabbing (KWin specific): Why would that be impossible to implement? You'd just need help from the toolkit to do that.

Window rules like always show a close button even if the window is not closeable: Working around broken apps? Fix your apps...

Accessibility features like big border and button sizes for all windows: Certainly not. It would even mean that you wouldn't get a disconnect between application and window manager implementing accessibility features.

Easily changeable window themes: Why wouldn't they be easily changeable? That's highly dependent on how the theming is implemented in toolkits. I guess it would be the case if you had a half-hearted implementation.

Shadows which are part of the theme (KWin would not paint shadows for a client-side window-decorated window): Why not? If KWin knows that the application is drawing its own decorations, it could draw the shadows, or you could make the application's toolkit be aware that it needs to draw the shadows. Either way, it's not impossible to implement.

There also doesn't seem to be a list of thing you'd end up winning:

Tear-free window resizing (when the client is doing the resizing, with a proper resize grip for example)

Better integration of resizing within applications (say "zooming" when going to fullscreen

9 comments:

Anonymous
said...

Sorry, but I find Martin's arguments more convincing. Everything you want to achieve through client-side decorations can be done through D-Bus. Expose D-Bus functionalities and let the window manager do whatever it wants to do with the functionalities you export. There's no need for client-side decorations there. You just need to agree on an interface, and let the front-ends developers do what they think to be the best for their environment.

Anonymous: We need client-side windows for the reasons I listed at the bottom of my blog, and no, adding a "+" button in the frame doesn't solve it either. There's a few more details on the Wiki, as mentioned, and you'll find a number of articles about why window managers suck all around.

Hey guys, I'm the author of the gtk+ branch that implements client-side decorations.

Just to clarify some things, this branch will most definitely not force you to use client-side decorations. gtk+ will continue to work the way it does now as well. There will certainly be some regressions along with some advancements (when this feature is enabled), but I'm happy to work with different application and WM developers to improve that situation.

Some original motivations for this feature were to eventually have a single source of theming a gtk+ (instead of theming the WM and app separately), to possibly support Wayland or something like it, allow the toolkit to do interesting things with the titlebar (e.g., Chrome-like UI as Anonymous suggested), improved resizing so that the window border isn't ahead of the app contents as you resize, a good excuse to finally integrate default RGBA windows in gtk+ ;)

Google has expressed interest in dropping their custom client-side decorations in favor of using the upstream gtk+ one when it lands. I think this is a big win for Gnome/Fedora/Ubuntu, etc, as we can hopefully get nicer integration of Chrome with our desktop environments.

Last Guadec/Akademy in Gran Canaria I talked very briefly to one of the Qt developers from Nokia and he seemed to be interested in the idea, so this may not simply be some gtk+ crack being smoked. ;)

Anyway, I'm happy to talk to people about it further by email or irc if anyone has questions or concerns. I'll probably try to make my own blog post about it sometime as well.