Modality changes proposal

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

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.

I propose to add new state - _NET_WM_STATE_GROUP_MODAL, which defines
that window is in modal state and it is modal for its group.
When window has this new state, its transient_for property should be
interpreted in the ICCCM-defined way.

Also, we propose to add a special set of properties used to identify
groups of windows affected by some kind of modality. For group modality,
it might be _NET_WM_GROUP_MODAL property, type WINDOW[], and all windows
having the some value the same among them are declared to belong to some
group. This will allow to identify groups in a non-contradictive to
ICCCM way and to identify a set of groups, probably with crossing
boundaries. For parent modality, it is natural to use transient_for
since it points to that parent exactly. For other modalities, other
properties should be used.

Along with _NET_WM_STATE_GROUP_MODAL, we propose to add
_NET_WM_STATE_PARENT_MODAL state to identify parent-modal dialog.

2. Inability to handle mixed modalities.

Right now specification declares two kinds of modalities available -
parent modality(transient_for is set to parent) and group
modality(transient_for is set to 0 or group). However, it doesn't
declare how to handle the case when several modal dialogs exist, and
when they have different/same modality. There is a problem: it is not
specified how the WM should behave if there is more than one modal
window active in one group. I think this should be specified, even if it
only serves to bringing consistency among WMs. Also, it is not specified
what will happen when during group-modal parent-modal dialog is shown.

I think of modality in terms of layers. All windows are divided into
groups (there is also one group which is the union of the windows
without groups). 
When there are no modal dialogs all windows belonging to the same group
are in one layer. This layer is currently active layer.
If some parent-modal dialog is shown it becomes the part of it's
parent's group(parent should always be defined using transient_for) and
it is put on the active layer.
If some top-level is shown it becomes part of its parent
group(if that exists) or specified group(using group identification
property) and is put on the active layer. There should also be a way to
specify another possibility - to put the window on the same layer as
parent.
If some group-modal dialog is shown it automatically defines new(higher)
layer. This layer becomes active layer. 

Inside layers, the windows are organized in a tree-forest, based on
parent-child relation.

Now how this should behave: All windows on some layer should be kept
above all other windows on the lower layers.

It is clear that this definition is time-dependent - if we have two
group-modal dialogs the distribution of windows among layers will be
different if we show first dialog than second from the case when we show
second then first. 

Therefore, to allow layers to be calculated dynamically, I propose to
add property identifying the order in which the dialogs were shown.
This property should be set by WM when the transition from
WithdrawnState happens. The value used for this property should have
global meaning - if WM dies or restarts it should remain valid and
indicate the same order.

As such value I propose to use combination of server time from the last
event having such information plus additional counter which is used to
distinguish windows having the same time(this is just to avoid
round-trip to get real server time, probably round-trip is not so
noticable when WM initializes window?). We propose to name it
_NET_WM_MANAGING_TIME.

This value should be used to resolve situations when two
layer-defining windows belong to the same layer.

3. Application-wide modality

There are cases when it is necessary to show modal dialog which blocks
all other windows, including other modal dialogs. It is usually a
security notification/confirmation, critical resource or system state
notification. Such dialogs are usually application-wide - they block the
interaction with the whole application until the user "answers" to the
dialog.

For this purpose, it is natural to isolate such dialogs into a different
class of dialogs - application-modal. WMs can decorate such window
specially or taskbar/workspace switcher can indicate in some way that
this window is important to be noticed. Application-modal dialog should
always be above other windows in the application. If there are several
application-modal dialogs, the order between them is established based
on _NET_WM_MANAGING_TIME.

We propose to add new state, _NET_WM_STATE_APPLICATION_MODAL, indicating
that this window is application-modal. WM seeing such state should
disregard any other modality-controlling states. To identify application
windows, we propose to use WM_CLIENT_LEADER property on the windows( or
define special client-window-group identifying property) - this
application-modal dialog should block all the windows which have the
same value of this property as the dialog has.

Denis.
Sun AWT team.