Re: Modality changes proposal

[Dominik Vogt <dominik vogt gmx de>]

On Tue, Oct 07, 2003 at 02:56:58PM +0400, Denis O. Mikhalkin wrote:
> 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.

You can achieve modality with the proper settings of all the
blocked windows' focus policy to the "No Input" ICCCM focus model.
It may be cumbersome, but should definitely work on any ICCCM
compliant WM.

> The complexity comes from the fact that in one process several Java
> application can be run.

I don't understand how this should affect the window manager.  It
does not care about the process that creates the windows.

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

That can already be done with the window_group property.

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

Easily done by making the modal dialog a transient of the parent
window and temporarily setting the focus model of the parent
window to "No Input".

> There is a system controlling application, which sometimes
> needs to block the input for the whole process - so here comes client
> modal dialog.

Blocking other applications' focus is evil, evil, evil.  This
simply is not the right way to write applications.  If the
controlling application can not live with the specific application
active, put it to sleep with a SIGSTOP or design other means to
control it.  The window manager is definitely *not* the right
place to establish control over the application.
 
> 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.

Which doesn't necessarily mean it's a good solution.  On windows,
the user has almost no control over what is happening on the
screen.  Many of us think this is bad.  Don't expect the wm spec
to become a "windows compliance enforcement" spec.  I guess most
of us feel more obliged to give control to the user than to give
it to the developers.

Ciao

Dominik ^_^  ^_^