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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz