Re: Modality changes proposal

["Denis O. Mikhalkin" <dom sparc spb su>]

On Fri, 2003-10-24 at 20:16, Lubos Lunak wrote:
> 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.
Strictly speaking, I don't need to prove anything. You've made a
statement and assumptions in "specification", but you didn't prove they
are correct. But if I assume that your statement and assumption is true,
to prove the opposite I would only need to provide a contradicting
example:
1) Main window, a set of tool windows(popups), then dialog modal the
them all but popup to the main window so that it behaves exactly as all
other owned windows behave: when main window is
hidden/iconified/transfered to another desktop/disposed of modal dialog
behaves exactly the same way as any other popups(when it doesn't
contradict to the definition of modality).

2) Two group-modal dialogs, the second one is modal to some set of
windows, but to implement it one needs to set transient_for to the first
modal dialog.
3) Set of windows, group modal dialog for them, set of windows about it,
group modal dialog for them - to implement this toolkit needs to set
transiency on the windows which are not transient.


> 
> > - 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.
If something is not specified we can't rely on it.

> 
> > 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?
Could you please be more specific? What didn't you understand? Do you
have any contr-arguments?

> 
> >
> > 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?
Hmm, I don't see how this is related to my proposal. Seems like its
meaning got lost along the way. Please reread my proposal once more, you
are assigning me statements that I didn't make - _NET_WM_MODAL_FOR is
not the same as WM_TRANSIENT_FOR.

Denis