Re: Modality changes proposal

[Lubos Lunak <l lunak suse cz>]

On Wednesday 15 of October 2003 17:09, Denis O. Mikhalkin wrote:
> On Tue, 2003-10-14 at 18:05, Lubos Lunak wrote:
[snip]
> >  Interesting. I don't remember ever seeing windows created like this. But
> > it still doesn't prove in any way that modality and transiency
> > relationships are something different. C will be transient for A's group,
> > B's will be transient for C, D will be transient for B's. Sure, it may
> > require extending WM_TRANSIENT_FOR, but that's about it.
>
> Can you prove that they are equal? The need for the change the use of
> transient_for in _NET comes from two reasons:
> - it is not proven that modality and transient are equal

 You want the change things. You should be the one proving that (even 
extended) transiency is not sufficient for modality.

> - it is the hole in a spec which can lead to non-equal interpretations
>
> If you look at my picture once more you can find that it is possible to
> implement this by dynamically changing transient_for/group properties of
> the windows. It is not said anywhere that transient/group can be
> modified dynamically, and the whole concept of such properties being
> dynamically modifying looks ugly to me(though Metacity supports it, and
> I suspect it is unsaid part of the protocol basics).

 Given that using transiency for modality would need extending the 
WM_TRANSIENT_FOR property anyway, saying that it can be changed at runtime 
(most WMs handle that anyway I'd say) or making cleared description of it 
shouldn't be a difficult side-effect.

> Also, this change
> can't be made synchronously and it can't be made without side affects(if
> C was over some B before B was made trasient for C, C will go down).

 That's how it should be. Since when should modal dialogs be somewhere else 
than above their main window?

> Also, this makes windows for which transient_for was not meant to be
> used have transient_for property set(B's).

 So?

>
> Implementation of this kind of modal structure, even if implemented
> correctly by WMs, requires some complicated techniques from the
> toolkits, while the solution I propose is much simplier and robust, and
> can be easily implemented by WMs.

 And the thing that will make it simpler is adding property _NET_WM_MODAL_FOR, 
which is basically like WM_TRANSIENT_FOR, just for modality? How can this 
make things more complicated for toolkits and simpler for the WM?

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