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

[Lubos Lunak <l lunak suse cz>]

On Wednesday 01 of October 2003 15:29, Dominik Vogt wrote:
> On Wed, Oct 01, 2003 at 02:54:45PM +0200, Lubos Lunak wrote:
[snip]
> > >
> > > 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)

 Those problems exists already with WM_TRANSIENT_FOR. And except for the 
loops, extending it won't change anything about that. In fact, this 
_NET_WM_TRANSIENT_FOR could be stricter and say which things are not allowed.

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

 I think the loops are not necessary. If I want WM_TRANSIENT_FOR pointing to 
more than one window, that should mean those windows have no connection 
between them (because otherwise I could go e.g. with being root transient). 
That of course doesn't mean somebody will not try to do it, as always, but 
the WM could simply detect the loop and cut it somewhere - it'd be their 
fault after all.

 Actually, on the other hand, if this would be also used for more grained 
control of which windows are blocked by STATE_MODAL, then this could happen. 
Hmm, perhaps that's not a problem at all. In the picture above, there are no 
loops, as all the arrows point up.

 So, if your rule for raising is raising all subwindows, raising D would 
result in raising E and F. If your rule for raising would be raising for 
mainwindows and subwindows, then it'd be raising A B D C E F (from parents, 
and from left). That looks theoretically doable. The question is whether that 
would be also doable in practice. I was sweating blood when implementing root 
transients to be transient for all windows in the group. But now that I have 
the code, extending it could be quite easy.

 Maybe I should just try to implement it first.

[snip]
> >  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.

 That could help me with focus stealing prevention, but not with placement. 
Unless I'd use root transiency. But I'm afraid this wouldn't turn out to be 
easier than extending WM_TRANSIENT_FOR :-/.

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