Re: modality, hinting to the WM, and GtkWindowGroup

["Owen Taylor" <otaylor gtk org>]

In the end, the question here really isn't what we call different
types of modality -
the relevant questions are: what are the different situations that
users should see?
how do we represent those situations through the GTK+ API? if it isn't
sufficient,
what extensions are needed?

By far the most common case is:

There is a single toplevel window, with associated dialogs, one of those
dialogs is modal, and should block input to the toplevel window and
its sibling dialogs.

There might be one of these toplevel windows or multiple per process
... it doesn't
really matter to the user, because the process is generally not a
user-relevant concept.

This situation is modelled pretty well by GtkWindowGroup; there may be
deficencies
in how we hint this situation to the window manager, but that isn't in
itself a reason
to add additional GTK+ API. If we just fixed bug 59724, and set the group leader
to correspond to the GtkWindowGroup, that should be sufficient information.

So, what are the additional use cases?

Do we need dialogs that span the entire process, other than for
compatibility purposes?

Do we need "treelike" modality where you have a set of windows in
transient for relationships where some windows block their parents
and some don't?

Once we feel we have a handle on the use cases, then the question is
how to extend the current GTK+ API to match the use cases. It *may*
be right to completely ditch the current GtkWindowGroup API and
mark it as deprecated, but this has a bunch of downsides; for one thing,
it's going to make a muck of the GTK+ internals: GtkWindowGroup
is deeply tied into the implementation of modality in GTK+, having
GtkWindowGroup for compatibility and also some other different modality
system would be a mess, and have all sorts of ill-defined corner caess.

This is what I don't really see as being explored properly in your mail -
gtk_window_set_modal_to_parent() / set_modal_to_enter_application()
may have some relationship to the NET WM hints, but its not clear to
me how they relate to modality *inside* GTK+. (Not to mention how they
relate to modality on Windows or OS X...)

Regards,
                                                           Owen

P.S. - I think the confusion about whether bug 307095 has any relationship
 to this problem at all is a difference in how bug 307095 is viewed.
 You (and maybe Todd) apparently see the situation as that "window B"
 as being different from the normal modality that GTK+ has ... it should
 block its parent, but not to "window C". But this doesn't make any
sense to me ...
 There's nothing special about window B; its just a normal modal window.
 The special thing is the relationship between window B and window C.

 Maybe modal windows should *never* block events to their transient
 children. Maybe there should be some way to mark a window like a
 drawer as being "attached" to its parent, so it shares its modality with
 the parent. But in any case, this special B->C relationship should apply
 no matter how B is modal as compared to other windows in the
 process.

 So to solve bug 307095, what we need is not new ways to set things
 modal, but ways to add *exceptions* to modality.