Re: Modality changes proposal

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

Hi,

did you guys have a chance to look at the proposal?

No matter what you think about it - whether it is good, requires
additional work, impossible to implement, has flaws or just sounds
stupid - please reply to it so we can get your opinion. Any such
information is important for us to decide how to proceed further with
modality bugs we have.

Thank you.

Denis

On Thu, 2003-10-02 at 17: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.
> 
> 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.
> 
> 
> _______________________________________________
> wm-spec-list mailing list
> wm-spec-list gnome org
> http://mail.gnome.org/mailman/listinfo/wm-spec-list
>