As some of you have requested discussion of the issue of GTK taking over the responsibility of window border decoration from Metacity, I’ve raised the issue on gtk-devel-list. Hop over there and throw in your two pennies, if you like.
In unrelated news, this is the hundredth post on this blog. Hurrah!
I’m not subscribed to gtk-devel-list, so I’ll add my two cents here:
To me, the big wins for X11’s scheme are that (a) the close-box always works, even if the app is hung, and (b) apps don’t get grandiose ideas about putting special branding or widgets in their title bars (Google Chrome, RealPlayer, Microsoft Word 95, Safari), promoting consistency of appearance and discouraging ‘where is it safe to click to move this window’ games.
I suspect that if GTK drew window borders, the above advantages would be lost.
Also, it sounds like it would be very difficult to extend this behaviour to non-Metacity window managers. Sure, Metacity and Compiz share a theme format, but what about people using GTK+ applications under awesome or xmonad or blackbox or icewm or (more realistically) Kwin or Windows or OS X? Would they have to render their themes into Metacity format and set the appropriate gconf keys to get these things working?
I’m also not subscribed to the gtk-devel-list. What all these people seem to miss is that once GTK can take care of its own borders, there is no need for supporting the metacity theme format. Treat the windows as yet another widget to style using the GTK+ theme. This does not take away the consistency as even currently each app is free to register its own gtkrc ruleset that turns the entire window contents red for example. In fact all it does is increate the consistency as we can get stuff like smooth consistent gradients that extend across the window/decoration boundary for free.
I would also welcome a feature that changes the decoration color for suid/root programs running inside a user session (for example adding a slight red tint to the border) or marking terminal windows that contain an ssh session so I don’t accidentally shutdown a remote machine.
Again, adding this won’t likely have any negative effect on the consistency, apps are perfectly capable of breaking the consistency right now and you don’t see many of these in GNOME SVN.
No it’s not a good idea, the correct way to do it is by extending the WM specs.
@Patrys : that way non-gtk apps will look totally out of place, that’s not needed
Non-GTK apps already look totally out of place for me. And they’ll get to keep their current look including the Metacity decorations.
It’s like voting against smooth crisp fonts saying legacy bitmap fonts will look bad in comparison ;)
Why give the job to the GTK application? How about getting the GTK theme engine to do this in the background under GNOME?
This way we have a single technology that handles theming and it all remains completely transparent.
And (sorry about double posting!) as far as moving / right clicking windows is concerned, that could be as simple as Metacity allowing window drags to happen with mouse events in the window client area. Since we’re going to be messing with GTK a lot anyway, it could be patched so that widgets like menubars and frames pass unused events upwards to their parents. Thus, a window could be controlled from a click on any portion which does not already respond to clicks.
But if the theme engine is doing the job, it IS being done by the application process– just by its toolkit rather than any conscious effort by the app developer.