unity-design team mailing list archive

[Scott Kitterman <ubuntu@xxxxxxxxxxxxx>]

Still forwarding on the assumption Martin's mail won't get through. 

"Martin Gräßlin" <kde@xxxxxxxxxxxxxxxxxxxx> 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/