Re: Compositing managers spec

[Sanel Zukan <sanelz gmail com>]

Hi,

> I think that things like this should be standardized as _NET_CM_WINDOW_*.

+1

> If we decide to use the _NET_CM namespace for composite managers, then I

+1 too. 

Following this, _NET_WM_WINDOW_OPACITY could be renamed to 
_NET_CM_WINDOW_OPACITY?

> I think that we should try to build it a separate spec on top of EWMH,
> because there still may be composite managers without a window manager
> functionality. Having it in one spec can lead to a point where things get
> mixed up, and it's not clear who (WM or CM), should be in charge for a
> specific window property.

Quite true. At first I was more for integrating cm specs with EWMH
because, for me, it looked naturally. On other hand, people can ship
separate composite manager apps without bothering to add window
management support. Heck, current development EDE version have compositing 
as separate application (althought that will be changed).

> Composite managers will always want to have a finer differentiation of
> the window type, than the current _NET_WM_WINDOW_TYPE types provide. 
> I think that something like _NET_CM_WINDOW_SUBTYPE could fullfill such 
> task. If we find a type description that makes also sense from the window 
> manager point of view, then we can define it as _NET_WM_WINDOW_TYPE window 
> type.

Why need to duplicate efforts? Composite managers can regulary fetch
window type (which is related to wm) and do whatever they like with
them (in a sense of presentation; handling still should be done by wm). 
If they want to paint the same type differently (e.g. menu), interested menu 
can use "styled" properties, like _NET_CM_STYLE_SHADOWED or similar. At
the end, integrated cm/wm solution can combine them both removing potential
ambiguities or duplications.

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