Re: Modality interpretation

Lubos Lunak wrote:

On Wednesday 26 of November 2003 17:59, Gregory Merchan wrote:

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

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.

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]