Re: Modality interpretation

[Bill Haneman <Bill Haneman Sun COM>]

Lubos Lunak wrote:

> 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?
Pretty much.  A server grab will definitely break stuff, a keyboard grab 
will, er, prevent keyboard input to the assistive technologies ;-)  
which is only acceptable in a few corner cases.  Doing a pointer grab is 
sure to cause problems for GOK.  Use of override-redirect windows 
(especially if they do not honor WM_STRUTS) will also break GOK usage.

- Bill