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.
I think there's a bit of confusion of terms here. Client-side windows are not the same thing as client-side window decorations. Qt has had client-side windows for quite some time.
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.
4 May 2010 at 18:21
Anonymous said...
@hadess: I've never experienced tearing in Qt/KDE, so I don't know what you're talking about. Something related to GTK+ only maybe ? If so, then as you said, fix your own broken design.
And regarding your answer to the other Anonymous, sorry but even after re-reading your post as well as the wiki, I can't find any valid reason, sorry.
4 May 2010 at 19:42
Anonymous said...
besides web browsers which apps would want to do this
"allow the toolkit to do interesting things with the titlebar (e.g., Chrome-like UI as Anonymous suggested)"
"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."
Instead of apps integrating into DE, force the DE and every other to integrate with Chrome
Blast: somehow I'd managed to take more than 4,096 characters in my argument. Suffice to say I strongly disagree with client-side window decorations.
17 May 2010 at 00:16
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 fullscreenProper way to do tabs in titlebar, a-la Google ChromeWindow-as-a-document/object (see the tab interaction part of this Empathy UI review, which would enhance the integration between applications and file managers)And that's just the things I see myself as winning. There's more technical details on the GNOME Wiki. Update: Got my knickers in a twist over Client-Side Windows vs. Client-Side Window Decorations, fixed up links and text.
"Client-Side Window Decorations and misconceptions"
9 Comments -
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.
4 May 2010 at 14:32
I think there's a bit of confusion of terms here. Client-side windows are not the same thing as client-side window decorations. Qt has had client-side windows for quite some time.
4 May 2010 at 14:38
Anonymous: How would D-Bus integration give you tear-free window resizing?
Alex: Yeah, I completely messed that one up, fixed in the update. Thanks for the notice :)
4 May 2010 at 14:51
Why do you need client-side window decorations?
The only good example I have read is "to make windows look like Google Chrome".
So why not just add top-level tabs and a "+"-button in the Window Manager and call it a day?
That would probably solve 99.9+% of client side window decoration usage and give you a very simple and consistent way to implement it.
4 May 2010 at 16:13
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.
4 May 2010 at 16:34
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.
4 May 2010 at 18:21
@hadess: I've never experienced tearing in Qt/KDE, so I don't know what you're talking about. Something related to GTK+ only maybe ? If so, then as you said, fix your own broken design.
And regarding your answer to the other Anonymous, sorry but even after re-reading your post as well as the wiki, I can't find any valid reason, sorry.
4 May 2010 at 19:42
besides web browsers which apps would want to do this
"allow the toolkit to do interesting things with the titlebar (e.g., Chrome-like UI as Anonymous suggested)"
"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."
Instead of apps integrating into DE, force the DE and every other to integrate with Chrome
5 May 2010 at 00:26
Blast: somehow I'd managed to take more than 4,096 characters in my argument. Suffice to say I strongly disagree with client-side window decorations.
17 May 2010 at 00:16