On Monday 28 of January 2008, Sanel Zukan wrote: > 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.
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. > Following this, _NET_WM_WINDOW_OPACITY could be renamed to > _NET_CM_WINDOW_OPACITY? 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. > > 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. 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. > 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). Agreed here. Just because people these days seem to think integrated CMs are the way to go that doesn't mean that can't change their minds again, so we should not prevent that. > > 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). Right. Where should _NET_WM_WINDOW_TYPE be insufficient for CMs? -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http//www.suse.cz _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
