> 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 _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list