Re: Modality changes proposal

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

On Tue, 2003-10-14 at 18:05, Lubos Lunak wrote:
> On Wednesday 08 of October 2003 17:33, Denis O. Mikhalkin wrote:
> > On Wed, 2003-10-08 at 16:37, Lubos Lunak wrote:
> [snip]
> > > > Practical example: developer has a group of windows, then shows modal
> > > > dialog for this group, then shows some more windows(they won't be
> > > > blocked), then he shows another modal dialog for the group which is
> > > > child of previous modal dialog. Right now: there is no way to have this
> > > > dialog a child, and actually, there is no way to create such a modal
> > > > dialog in _NET, but it is possible to do it on other platforms, WMs and
> > > > protocols.
> > >
> > >  This description looks a bit ambiguous to me, so let's guess:
> > >
> > >  A A A   B B
> > >  \ | /  /   /
> > >    C
> > >
> > >    D
> >
> > Hmm, to me what I wanted looks like this:
> > (I use numbers to show layer in terms that I described in the proposal)
> > 0 A A A
> > 1   C
> > 2 B B B
> > 3  D
> > So D is above all other windows, Bs are above C and As, C is above As. C
> > and D are modal, As and Bs are just regular windows. That's what we
> > NEED. Note also that the picture needs to be looked at  sequentially -
> > first only windows at 0 layer, then windows of layer 1 are added and so
> > on. Think it is possible to do it in a current specification?
> 
>  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
- 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). 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). 
Also, this makes windows for which transient_for was not meant to be
used have transient_for property set(B's).

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.

> 
> > > > > [Snipped something quite long and complicated.]
> > > > >
> > > > >  Do you have any real application that actually needs that? I'd like
> > > > > to see the reasons for this in practice.
> > > >
> > > > The actual application is Java API. In Java API it is possible to
> > > > create
> > >
> > >  Well, I don't know Java API.
> > >
> > > > hierarchies, and to set some of the windows to be modal. We have
> > > > requests from the people for having mixed modalities, and to have them
> > > > working consistently across platforms. Everything people ask from us is
> > > > possible to implement on Windows and impossible on Linux.
> > > >
> > > > The complexity comes from the fact that in one process several Java
> > > > application can be run. Each of the application might want to show
> > > > modal dialog - so groups are necessary. Application might want to show
> > > > several modal dialogs, all are group-wide, so here comes the need for
> > > > layers, right now only ONE group-modal dialog actually works. Some
> > > > applications like to have also parent-modal dialogs, for quick and
> > > > temporary requests - so here comes the need for correctly mixing
> > > > group-wide and
> > > > parent-wide.
> > >
> > >  We already have way to specify parent-modal and group-modal dialogs,
> > > with parent and group transiency. I'd say it even works with KDE3.2 KWin.
> > > Not that I know any real application using such complicated relations
> > > with which I could test it.
> >
> > Java could be the one, but until I am 100% sure that all _NET WMs
> > implement modality similarly and that every situation when parent
> > modalities are mixed with group modalities they work equally I don't
> > think we'll risk using them both - we need to make sure it works on all
> > platforms, on all WMs equally.
> 
>  Well, I'm afraid making all WMs out there perfect is scheduled only for year 
> 2043. No wait, it's actually 2072. Until then, we all have to live with the 
> fact that nothing is perfect. If you e.g. look at http://sweb.cz/tripie/
> utils/wmctrl/ , you can see that some even quite widely used WMs have poor 
> support for this spec, if at all. What makes you think they'll suddenly get 
> better, as soon as your modality proposal makes it into the standard?
True thing, we won't be able to make all WMs implement new
specification. But this can be said for every proposal here, so don't
you say people should stop proposing anything, huh? And it is much
simplier to detect whether some WM supports some part of the spec(vi
_NET_SUPPORTED) then to detect all those flavors of WMs modality or
anything else implementations WMs have.

Another thing is that if proposal becomes part of the _NET it might be
possible for us to make sure that at least _some_ WMs support it, using
our friend/commercial/community-relations. While if it is not part of it
then we can't expect them to cooperate on this matter at all.

Denis