unity-design team mailing list archive

[Scott Kitterman <ubuntu@xxxxxxxxxxxxx>]

Once again forwarding for Martin.

On Wednesday, June 09, 2010 05:19:06 pm Martin Gräßlin wrote:
> Am Mittwoch 09 Juni 2010, 20:48:39 schrieb Cody Russell:
> > Anyway, I just wanted to comment on this statement and point out that
> > this is not a hugely difficult problem to solve with some cooperation
> > from a WM.  I would assume a WM can monitor _NET_WM_PING and either
> > popup a dialog, or we could create a hint to expose a region of the
> > close button to the WM for this purpose.
> 
> Of course this would be possible, but it has the drawback, that we have to
> change each existing window manager to get something what is working today.
> But that belongs on the wm-spec mailinglist and not to this one. In general
> I must admit that I'm opposed to add any changes to KWin to make something
> work which I consider as wrong. And in general I don't like adding
> workaround for apps - and that's what it would be.
> 
> > This strikes me as being a lot less work than trying to do in our WM
> > what you've done in KWin.
> 
> I hope you are aware that the last painting is done by the compositing
> manager which in general is the same as the application which provides the
> decoration ;-) And if you want shadows you start to require the
> compositing manager as a second process nevertheless. So I don't think
> it's possible to get it in just one process.
> 
> But thanks for being so clear that all you want to achieve is nice theming
> which is easier to implement with CSD than with fixing Metacity. This would
> be totally fine if your change would only affect GNOME. But it affects all
> desktop environments. And for KWin it would be a minor issue compared to
> e.g. tiling window managers where maximize/minimize buttons do not make
> sense. So while you improve the rendering in GNOME you would break all
> other desktop environments. And as already stated there are some unfixable
> issues at least for the lifetime of KDE 4. KWin core does not know the
> position of the decoration buttons. So it is impossible to have a
> consistent look and feel between KWin and GTK client side decorations in a
> KDE environment!
> 
> I am sure that you will require the WM to allow CSD, but I don't trust
> applications any more. If we start to add CSD to GNOME desktop, we invite
> apps to go the Chrome-way and they will start ignoring everything and
> enforce the CSD. No matter if the WM wants it or not. Now this might sound
> like stupid blah, but I'm speaking with the experience of developing a
> window manager. Unfortunately I see how many apps are broken because they
> play window manager and the app which is causing the most trouble uses GTK
> and wants to have CSD. (Hint if you want to guess the app: it's a browser
> and doesn't use decoration tabs). The number of GTK apps in my list of
> broken apps is quite high, so sorry that I am not confident that apps
> won't start to do stupid things.
> 
> Here is what I offer: let's sit together and define what we want to have
> from a window decoration theme engine. Let's define one format which is
> used in Metacity, KWin, Compiz and any other window manager who wants to
> support it. That way we can define something which will really increase
> the consistency between the different environments without breaking
> anything. This theme engine format could become a freedesktop
> specification.
> 
> > I disagree that our approach is fundamentally flawed.
> 
> It would be bad if you would not believe in your own work ;-)