Still forwarding on the assumption Martin's mail won't get through. "Martin Gräßlin" <[email protected]> wrote:
>Am Montag 07 Juni 2010, 20:54:06 schrieben Sie: >> No, it couldn't. Let's say my application is a 3-d app and when I hover >> over the toolbar button I want a "sparkler" style particle effect as the >> animation behind the button. It would make sense that this animation >> would go to the edge of the full window, but it would look silly if it >> stopped at the title bar. Passing a 3-d context with particle >> animations to the window manager to render doesn't make much sense. >Just for the record: this is possible, too. Up to now nobody wanted to have >such a feature, so it is not yet supported. But in general there is no problem >that the app renders into an FBO and blits the texture to the own background >and passes it to the window manager - either as a GLTexture or more likely as >a pixmap. So the window manager could just blit the pixmap. As we are using a >composited window manager it would not result in problems as the window and >the decoration are painted in the same painting pass. Furthermore I think that >visual appearance should never be more important than functionality. I'm >argumenting against CSD because we will lose functionality. Oh and if the >sparkle effect is passed to the WM for rendering it's also possible to sparkle >outside the bounds of the window. And that would be could, wouldn't it? That's >impossible with CSD. > >Like all the arguments in this discussion it's a no-brainer for KWin. If you >just need some features: talk to us. It's way easier to add support for your >usecases instead of breaking all apps. Nobody has ever contacted us about >missing features and the discussion shows that there is a lot of missing >knowledge about what's possible with decorations - that is sad. You are in the >process of breaking all apps based on a wrong assumption that your features >are not possible with reparenting decorations while most of the features are >already present in KWin - and those have been added before the discussion >about CSD started, so it's not a reaction on the needs of CSD. Same for window >tabbing. We started to add support before Chrome had a stable release on Linux >(I even think before Chrome had any release for Linux). > >Now after thinking about all the arguments you raised in the discussion for >CSD it seems to me that you have two issues you want to fix: >1. Metacity's theming support does not allow you to do what you want. >2. Fixing Metacity does not help you as you also have Compiz and Mutter as >first class window managers. >So it ends in being easier to break all apps instead doing something properly. > >As mentioned in my open letter: I want to help you. I am willing to spend my >time and expertise on this issue to ensure that we don't end with an utterly >broken CSD library in GTK 3. > >So here some possible ways to fix it. You can easily fix the second problem of >your three window managers by ditching Metacity and Mutter. OpenGL is a plugin >in Compiz 0.9, so you can use it for the non-composited mode. As Sam Spilsbury >illustrated Compiz can also be used to replace Mutter in Unity [0]. I think >the advantages are obvious: instead of three window managers, you just have to >support one. I know that Compiz is not perfect, but I think that Compiz devs >will happily accept the manpower you would waste in fixing all issues you >introduce with CSD. And speaking as a KWin dev: I would love to see a speed up >in Compiz development. > >The first issue is probably more difficult to fix as Metacity theming is >limited and very complicated (Aurorae only exists because it was too difficult >to implement Metacity theming for KWin) and Emerald is basically dead. But >there is the Cowbell project which has the potential to be a real great >solution (if Cowbell proofs to be useful KWin will eventually add support for >it). Cowbell would be perfect for you as it is a CSS theme engine and so one >CSS theme for app and decoration can be created. > >Another option is to use Aurorae in Compiz. You have seen the power of Aurorae >in the one screenshot I sent to this list - and that was the old 4.4 >implementation. Aurorae is designed in a way that it could even be used in >Metacity. It does not have any kwin dependencies and AuroraeDesigner proofs >that it is not even required to be tied to window managers. (In fact if I >would implement CSD I would use Aurorae as the theme engine, because it >provides everything which is needed and it would share themes and >implementation with window manager decorations). But given that Aurorae has a >kdelibs dependency I doubt you would want to use it :-( > >And for the record there is one more option which would solve all your window >manager related issues: switch to KWin. This might sound strange, but as we >have seen in the discussion, KWin supports all the features you want to have >or at least it is possible to add them. KWin is known to be feature rich >(unlikely there would be regressions compared to Metacity/Compiz), fast, NETWM >compliant, composited, non-composited, stacking, tabbing, tiling and rock >solid :-) You are looking for unorthodox and innovative ideas like CSD, so go >the innovative way to switch to a KDE based window manager in a GNOME desktop >environment. > >Martin > >[0]: http://smspillaz.wordpress.com/2010/05/11/thank-you-canonical/ _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
