Re: Modality changes proposal

[Lubos Lunak <l lunak suse cz>]

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.

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

 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.

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

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/