Re: _NET_WM_HERE (was Re: Do-not-disturb protocol)

[Lubos Lunak <l lunak suse cz>]

On Monday 23 January 2006 16:33, Tuomo Valkonen wrote:
> On 2006-01-23, Lubos Lunak <l lunak suse cz> 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: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/