Re: Modality changes proposal

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

On Tue, 2003-10-07 at 16:07, Dominik Vogt wrote:
> 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.
Yes, that's what we do right now, though I found that "No Input" doesn't
work with most of WMs, Global Active works more stably. However, we need
somehow also to control stacking order, because when non-modal window
appears above modal dialog, and modal dialog is not on a taskbar - it is
impossible to continue to work with application. If we could prevent not
only focusing of the window, but also prevent raising of some window(how
about WM_RAISE_WINDOW from WM to client, similar to WM_TAKE_FOCUS) then
I wouldnt' bother anyone anymore.

> 
> > 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.
Implicitly. See below.

> 
> > 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.
Did you try how it works? I didn't try it on KWin, but on Metacity it
works so that second dialog doesn't block anything. And I can't say it
is a bug in Metacity(however I have a patch for fixing this) - since it
is not specified in _NET how two group-wide modal dialogs will behave
when they are shown at the same time and have the same group. 

> 
> > 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".
I probably need to expand the term "mixing". I mean - having modal
dialog of different modalities on the screen, with different
hierarchical dependencies. For example - some windows, show group-wide,
then show parent-wide with parent blocked by group-wide. By our
specification this new dialog should be above group-wide. I can thinkg
of situations when it should be below. So there should be a way to
explicitly specify this.

> 
> > 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.
When there are several Java application in one process it means that
nevertheless they are separated they still can access some resources
from other application. So if one "application" shows modal dialog,
another shows modal dialog they shouldn't block each other - this can be
done by assigning different groups to them, right. But when the system
controlling application wants to show modal dialogs and IT MUST block
all modal dialogs belonging to all those groups - there is no way to do
it, window can only be a part of one group right now. Instead of asking
for possibility to mix group which is odd and too complex we can just
live with some kind of superior modality, we thinkg it should be
client-wide.

>  
> > 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.  
Well, an opinion. There are different opinions - that Window API is both
user and developer friendly. Being Windows user for years I never felt
the need to control anything, I don't understand what can be controlled
and why - I am sure most of the users, even users-developer, won't need
it as well. But developers do neet a control - to write applications
according to specification.

> 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.
What do you mean by "give control to the user"? What kind of control?
And how my proposal enroaches on this "control"?

Denis