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 ;-)
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
