[compiz] [RFC] Draft for a compositing manager specification
kde at martin-graesslin.com
Wed Aug 18 12:25:30 PDT 2010
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
Size: 316 bytes
Desc: This is a digitally signed message part.
More information about the compiz