extended WM_TRANSIENT_FOR (was Re: _NET: Disabling shading)

[Lubos Lunak <l lunak suse cz>]

On Wednesday 01 of October 2003 13:50, Dominik Vogt wrote:
> On Wed, Oct 01, 2003 at 11:32:52AM +0200, Lubos Lunak wrote:
[snip]
> > > > We may well need to have a richer language for expressing which
> > > > windows are modal shadowed though; at the very least, the spec needs
> > > > to be more clear about how to determine which windows are
> > > > unresponsive while a window of type MODAL is active.
> > >
> > > Wouldn't the window group hint be a good candidate?
> >
> >  Yes. I think we even have it in the spec already, in the description of
> > _NET_WM_STATE_MODAL :). I don't think there is need for more grained
> > specification of which windows it makes modal that what's currently in
> > the spec, as applications usually don't have more complex their internal
> > state of modality.
> >
> >  On the other hand, I wouldn't mind extending WM_TRANSIENT_FOR to be able
> > to point to more than one window, as I actually recently encountered a
> > problem related to this WM_TRANSIENT_FOR limitation. I'll try to write a
> > patch for the spec and post it.
>
> I'd rather do without that "feature".  Handling trees of
> transients is already almost impossible to handle gracefully
> without multiple paths in the window relationships :-P

 Why should there be multiple paths? KWin has a tree for such relations, and 
there are no loops or multiple paths. On the other hand, I have to admit the 
code for handling (and checking) that was a paint to write :-/.

 Anyway, I couldn't come up with any idea for solving my problem better than 
extending WM_TRANSIENT_FOR. But let me first explain the problem, maybe 
somebody will known something better. The problem is roughly like this:

 KWin (in the comming-soon KDE3.2) has a feature called focus stealing 
prevention - it simply tries to block all window activations that the user 
would find annoying (such as "you have new ICQ message" and so on). I already 
mentioned it here 
http://mail.gnome.org/archives/wm-spec-list/2003-May/msg00013.html . The 
basic idea is that a window is allowed to be activated by itself only if it 
belongs to the application with which the user most recently worked. For 
this, I need to know which windows belong together. Just using 
WM_TRANSIENT_FOR, window_group and few tricks like comparing WM_CLASS works 
for most cases.

 An example of a case I have problem with is a cookie dialog ("do you want to 
accept this cookie from site XYZ?"). Cookies are not handled by Konqueror 
itself, but a special kcookiejar daemon handles them in one place. As it's a 
separate process, WM_CLASS, window_group and similar don't work. WM_TRANSIENT 
for still can handle this, as long as there's only one Konqueror window - the 
dialog is simply made transient for the Konqueror window, and KWin knows that 
they belong together. The real problem occurs when you have two Konqueror 
instances, and they both receive a cookie. KCookieJar queues cookies, so it 
shows at most one dialog at a time, but this dialog in fact belong to both 
Konqueror windows - you cannot continue working with either of them, until 
you handle the cookie.

 So the dialog should be transient for both the main windows - otherwise the 
WM will fail to keep it above either of the windows, and focus stealing 
prevention will refuse automatic activation of the dialog. I tried to find a 
different solution, like explicit requests to activate the dialog, but I 
couldn't come up with anything usable. So this is the best solution I have, 
and unless there's some better way how to handle it, I'll possibly have to 
implement it, be it KDE specific extension or part of this spec.

 Any better idea?

-- 
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/