Re: extended WM_TRANSIENT_FOR (was Re: _NET: Disabling shading)

[Dominik Vogt <dominik vogt gmx de>]

On Wed, Oct 01, 2003 at 02:54:45PM +0200, Lubos Lunak wrote:
> 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 :-/.

The abuses of the transientfor hint I have already seen:

  - transientfor does not exist
  - transientfor mapped after the transient window
  - transientfor loops (A transient for B, B transient for A)
  - transientfor hint set to None (I think)

I fear I would have to add

      A   B
     / \ /
    C   D
     \ / \
      E   F

:-P

Assuming the WM is configured to automatically raise/lower the
whole tree of transients when one window is raised/lowered, in
which order should the windows be stacked if window D is raised
(lowered)?

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

Maybe extend the window_group hint to allow a window to be a
member of multiple window groups?  To reduce the confusion, only
the primary group should be considered for placement,
iconification etc.

Ciao

Dominik ^_^  ^_^