Re: Modality changes proposal

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

On Mon, 2003-10-06 at 19:40, Lubos Lunak wrote:
> On Thursday 02 of October 2003 15:45, Denis O. Mikhalkin wrote:
> > Hi,
> >
> > we encountered several problems with the modality implementation in
> > Metacity and it has been indicated that this problems mostly have roots
> > in a _NET specification. Therefore we want to propose several extensions
> > to the specification to fix such problems.
> >
> > 1. Misuse of TRANSIENT_FOR
> >
> > From the beginning, TRANSIENT_FOR was used for the purpose of
> > declaring hierarchies of windows, usually defining parent-child relation
> > among top-level windows, usually used for popup windows. It has been
> > defined that TRANSIENT_FOR points to some top-level window and that
> > there is some relation between such two windows. WMs were using this
> > relation to perform different tasks on such windows as on parent-child
> > group(minimize, hide, transfer across desktops, focus, raise and so on).
> >
> > In _NET, TRANSIENT_FOR is used for different purposes: to define modal
> > groups. Now there is no way to defien parent-child relation when it
> > might be needed. I think the meaning of TRANSIENT_FOR should be restored
> > and other means should be used to define these new relations.
> 
>  There's no need to restore the meaning, since it hasn't changed. It's just 
> that when STATE_MODAL was added, it was apparently deemed that parent-child 
> relation matches the modality relation (since a modal dialog blocking some 
> completely unrelated window is IMHO just plain wrong)
> 
>  Can you give some examples when the transiency relationship is not good 
> enough?
Parent-child relationship and modality are in a different dimensions.
There could be modal dialog for some group and it might have parent. Any
top-level window can have a parent - and mane WMs and platforms
interpret this relation differently, but they do, they decorate such
windows differently, they perform some actions on owned windows if some
action is performed on owner window. From the API point of view, all
those(non-modal) owned windows should look and behave similar. Now the
developer shows owned MODAL window - and it starts to work differently,
look differently. To the developer, modality is just one more
property(along with, for example, "undecorated" or "non-resizable" or
"enabled") - it just describes how this window behaves concerning
input(it is kind of "grabbing the input"). 

transient_for should be used for declaring hierarchies, while modality
is unrelated to any hierarchies. And as it can be seen from the post
about changing the meaning of TRANSIENT_FOR just confirms this statement
- you need to extend modality across different hierarchies.

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.
> 
> [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
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. There is a system controlling application, which sometimes
needs to block the input for the whole process - so here comes client
modal dialog.  

It is just one simple example of the WebStart process, and there are
millions of complicated applications which I can't speak of(since this
is propriatery information) but whose authors(big-fat software
companies) ask for providing such a complex API for them. Right now the
only restriction for this is platform - on Windows EVERYTHING works.

Denis