Re: Modality changes proposal

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

On Wed, 2003-10-08 at 16:37, Lubos Lunak wrote:
> On Tuesday 07 of October 2003 12:56, 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.
> 
>  As the post by Gregory Merchan shows, possibly no extending of TRANSIENT_FOR 
> is necessary.
It might be technically not necessary, but strictly speaking NOTHING is
technically necessary - some people are happy writing their programs
using assembler so they don't understand why all this might be needed.
However, how about cross-WM compatibility? If some ICCCM compliant WM
comes after non-ICCCM compliant, won't it be confused by the use of
TRANSIENT_FOR? That is, it might not, but will be the result the same as
the developer and the user expected to see from the application windows
having this TRANSIENT_FOR?

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

> 
>  A are the first windows, C is the first mentioned dialog, B are the some more 
> windows, D is the second dialog. I see no problem with this. B windows of 
> course will be blocked by C(well, they should be at least), and C will be 
> blocked by D, transitionally blocking also A and B.
> 
>  I don't see how this example should prove in any way that transient and modal 
> relationships are something different, unless I misunderstood it. And the 
> description above is just vague talking about some, might, could and many.
> 
> >
> > > [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.

> 
> > There is a system controlling application, which sometimes
> > needs to block the input for the whole process - so here comes client
> > modal dialog.
> 
>  Yes, I think there's no way how to specify modality for the whole 
> application, if it has several window groups.
So do you agree that it might be reasonable to add it to _NET? Think it
can be done the way I proposed or do you see a better way?

Denis