On Monday 23 January 2006 16:33, Tuomo Valkonen wrote: > On 2006-01-23, Lubos Lunak <[EMAIL PROTECTED]> wrote: > >> WM_CLASS/ROLE doesn't do the same thing, as it isn't usually unique for > >> each window. Session management is closer, but it only works over entire > >> stored sessions. > > > > But CLASS/ROLE should uniquely identify a window within an application. > > If some app can't get this right I don't think it'd get something else > > similar right either. > > The number of applications that bother to set class/role to anything > meaningful can be calculated with the fingers of one hand. Most of those > that bother with role at all seem to be KDE/Qt apps. And what about > multiple running instances of the application? Not that _NET_WM_HERE would > help over restarts there either, but it would for running applications > popping up windows. Of course, if programs bothered to set instance to > something different for every running instance of the program, or for every > different "session" that the same process may be running, the properties > could be useful.
I guess the window group could be used for this. Of course, if apps actually would set it in some useful way. > But I don't think there's any hope of most programs setting the properties > to anything sane, and thus the properties being nevertheless usually set to > something instead of being unset, become useless. Indeed, X session > management doesn't use the class/instance/role properties either. Infact, > another way to think of _NET_WM_HERE would be _NET_WM_UNIQUE_IDENTIFIER for > single-application session management within or across X sessions. A kind > of dynamically configurable class/instance/role with the configuration > interface on the window manager side. And you seriously expect apps that can't do something relatively simple as setting CLASS/ROLE to support _NET_WM_HERE? I don't see how pushing a kludge designed to workaround apps failing do things properly should help anything when it requires the same amount of work like the old thing plus some more work. For _NET_WM_HERE apps would need to be able (internally) uniquely distinguish all their toplevel windows in order to store this info - but if they manage to do this they can as well simply set ROLE. And with ROLE you should be able to uniquely identify any window in a specific application. CLASS/INSTANCE should identify different kinds of applications, and CLASS/INSTANCE/ROLE/PID/HOSTNAME (replace PID/HOSTNAME with SM_CLIENT_ID for sessions) should uniquely identify any toplevel window. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 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
