unity-design team mailing list archive

[Sam Spilsbury <smspillaz@xxxxxxxxx>]

On Wed, Jun 9, 2010 at 12:49 AM, Scott Kitterman <ubuntu@xxxxxxxxxxxxx> wrote:
> 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.

Might I add, before this statement gets taken out of context and we
end up with a flamewar, I might just add that of course, dropping
metacity and mutter aren't your only options here - rather, I think
the top priority is to rewrite the (ancient) metacity theming
interface such that it supports proper widgets in decorations, much
like KDecorationInterface does. Currently the interface is implemented
in such as way that there are functions to draw to a gdk_pixmap, but
these are quite complicated. I think all three could benefit from a
rewritten theming interface, which takes into account the needs of
windicators, etc.

As far as I know, with martin's NETWM idea to have the decorator paint
the "behind" of the window, this basically means that the window can
be reparented at 0x0 in the decoration, rather than the offset of the
decoration. This means that they are free to draw whatever they want
on top of the decoration (tabs, particles, etc) and have it all blend.

Developers would be nice though *cough*.

>>
>>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     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Sam Spilsbury