Re: Compositing managers spec

>  The _NET_WM_CM_Sn selection is already widely used and it's been in the spec 
> for a while, so it's a question if we want to break backwards compatibility 
> there just because the name doesn't quite look right.

Hm... currently this property (and/or _NET_WM_WINDOW_OPACITY) are
possible candidates for this spec (am I correct?). Anyone have
more proposals?

Just thinking; if there are only two properties for cm-s, I'm not sure
is it worth to write specific spec anyway. On other hand, it will be
much easier to add additional ones later :)

>  I'm personally hesistant to give official blessings to this ugly beast. I 
> don't think clients should be allowed to control transparency of the whole 
> window (especially when that includes decorations) - that's none of their 
> business.

:) Then, how will external cm and wm/desktop/etc. communicate in uniform 
way?

Regarding to this, for some time I was planning to propose something like
_NET_WM_WINDOW_REGION_OPACITY where some window parts would be
opaque/translucent; e.g. menu could be translucent but other parts
opaque.

But, if there are good reasons to remove it, I will not be the one who
will start to yell :)

>  This problem actually already exists in the spec and even separating the CM 
> part won't solve it completely. Current spec mixes things WM is reponsible 
> for, that the clients are responsible for and that other tools like pagers 
> are responsible for (and the bad thing is that this is often even not 
> explicitly specified). A separate CM spec probably makes sense, but it'll 
> have to share things with the WM spec anyway.

Yes.

--
Sanel Zukan
http://equinox-project.org