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