[compiz] [RFC] Draft for a compositing manager specification

[Martin Gräßlin]

On Sunday 15 August 2010 23:14:48 Thomas Lübking wrote:
> Am Sunday 15 August 2010 schrieb Martin Gräßlin:
> > On Sunday 15 August 2010 16:19:04 Sam Spilsbury wrote:
> > > The compositor should set the _NET_CM_SHADOW_SUPPORTED hint and
> > > clients should set the following information in the _NET_CM_SHADOW
> > > property on the window.
> > > 
> > > 0 | shadow color (32 bit depth)
> > > 1 | shadow radius
> > > 2 | shadow x offset
> > > 3 | shadow y offset
> > > 4 | Number of shadow rects ( > 1 if the window is nonrectangular )
> > > 5 | A list of rects specifying shadow extents for each rect.
> > > 
> > > In the case where there is more than one rect, the compositing manager
> > > should automatically clip shadows  which are not "border" shadows.
> 
> Do you really want to let clients control shadow color, dimensions &
> offsets? Shadows resemble a light model, but with such setup they'd
> probably end up like psychodelic ;-)
> ("I - that is /ME/ - is the most important client on the block and I - that
> is *ME* - want the biggest and most colorful shadow!" :-)
> Even if not, it would end up like Gtk+ an Qt look different - again :-(
Yeah that's a serious issue, I am afraid of the same thing and thought about 
it before posting the idea with the pixmaps. I think the API above is too 
simple and you can't really get the light model. If you have to specify the 
pixmaps you will have to think about what you want and correctly implement the 
light model. But that's probably also only wishfull thinking.

Nevertheless I think we need a way to let clients influence the shadows. The 
CM can't know the light model of the client and just assuming "We have Oxygen" 
does not work, as there is also GTK. So for undecorated clients it would make 
sense to allow influence on shadows, while for decorated clients the WM should 
have the control. I must say that I really like the way it's handled in KWin 
with giving control of shadows to the decoration. So we could specify that the 
decoration is responsible for the shadows. The drawback of this is, that if 
some $STUPID_APP thinks to be important and wants to have red shadows, it's 
going for doing stupid things like client side decorations (CSD). So thinking 
about it: we have the chance to discourage usage of CSD and explicitly allow 
the CM to ignore shadow change requests.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/compiz/attachments/20100818/062d5c3c/attachment.pgp>