Re: Modality interpretation

[Lubos Lunak <l lunak suse cz>]

On Wednesday 26 of November 2003 17:59, Gregory Merchan wrote:
> Hi.
>
> I'm working on X property guidelines for GNOME applications so that app
> windows are treated correctly by at least GNOME HIG compliant window
> managers. I need to make sure I'm interpreting the EWMH correctly.
>
> There are three levels of modality recognized by most environments.
> The Motif input mode hint covers these, though the terminology is
> different from that of Windows or MacOS.
>
> 1) A "document modal" window prevents the user from interacting with
>    one and only one other window on the screen. The user is free to
>    interact with other windows.
>    (MacOS X now uses "document modal sheets" for this purpose.)
>    This is Motif's  MWM_INPUT_PRIMARY_APPLICATION_MODAL hint.
>
> 2) An "application modal" window prevents the user from interacting
>    with any other window of the same application. The user is free
>    to interact with windows of all other applications.
>    (Open dialogs on Windows and MacOS are usuaully like this.
>    This is Motif's  MWM_INPUT_FULL_APPLICATION_MODAL hint.
>
> 3) A "system modal" window prevents the user from interacting with
>    any other window. The user must dismiss the system modal window
>    before doing anything else.
>    (Logout dialogs are usually like this.)
>    This is Motif's  MWM_INPUT_SYSTEM_MODAL hint.
>
> There are supposedly some other kinds of modality, but, short of
> extraterrestrial invasion, I'm not going to concern myself with them.
>
> As I read it, the EWMH supports only the first two kinds of modality.
>
> 1) For a "document modal" window (MWM_INPUT_PRIMARY_APPLICATION_MODAL),
>    an application should set WM_TRANSIENT_FOR to the parent window, and
>    set the _NET_WM_STATE_MODAL hint.
>
> 2) For an "application modal" window MWM_INPUT_FULL_APPLICATION_MODAL),
>    an application should leave WM_TRANSIENT_FOR unset, and set the
>    _NET_WM_STATE_MODAL hint.
>
> So, I have these questions:
> 1) Is my interpretation correct?

 Probably. The spec's support for modality is possibly a bit vague. I don't 
think there's anywhere in the spec said anything that would guarantee you an 
application modal dialog. As Ben pointed out, you could get application modal 
dialog with making the dialog transient for the whole group, but this would 
work only if the whole app has only one window group.

> 2) What is an "application" for an "application modal" window?

 This is similar. The spec doesn't have a concept of application. I need this 
concept in KWin too (for focus stealing prevention), and it's a rather huge 
function trying to guess which windows belong together based on transiency 
hints, client leader, pid and similar things.

> 3) How might a system modal window be created without a pointer, keyboard,
>    or server grab, so that accessibility technologies may still be used?

 AFAIK system modal windows are frowned upon here (I guess people here 
remember the Windows dialog 'do you want to restart windows? ok' , or 
whatever it says exactly). Is there really no way to support accessibility if 
the dialog has input grabs?

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