modality, hinting to the WM, and GtkWindowGroup

["Elijah Newren" <newren gmail com>]

Hi all,

Sorry for the long email.  As suggested by Owen in bug 340167 (which I
really should have split into two separate bugs), I'm trying to
provide a writeup of some problems relating to modality.  I've already
got a tracker bug for these issues filed as bug 340166.  There's
_several_ separate gtk+ issues:

* Correct hints to the window manager *

Motivation:
Users often get confused by windows that they can't type or click in
if they are allowed to focus the window.  Modality can be even more
confusing in special cases where the user might not even be aware of
the existence of the dialog which happens to be modal (e.g. due to it
being totally obscured by the window they are trying to type in or it
being on a different workspace).  Metacity and other WMs try to help
the user (stacking the windows correctly, placing them appropriately,
warping modal windows to the right workspace when needed, and always
focusing the modal window instead of the frozen one), but the correct
hints are needed in order to handle this.

Where-it-works-now:
In the very common case that the application has exactly two windows
open (the modal window and the window it is modal to), things will
happen to work right.  The reason the remaining problems have gone
ignored for so long is precisely because this two-window case is so
common.

Problem:
The main problem here is with gtk_window_set_modal().  It leaves the
job of setting hints up to the application author to do separately,
which is somewhat suboptimal, but much more importantly is that its
documentation instructs app authors to use the wrong function to set
the hint.  gtk+ only currently supports modal-to-"application"
behavior, while using gtk_window_set_transient_for() can only hint
about modal-to-parent-window behavior.  Further, there is no gtk
function to set the correct hint; one must either use X or gdk to set
it.

* Documentation and meaning of GtkWindowGroup *

Problem:
GtkWindowGroup is poorly documented.  It is also abused/misused. 
There may even be some arguing about what it should mean, though that
may just be due to its poor documentation.

Solution:
I think GtkWindowGroup should be used to mark windows which are seen
by the user as being part of the same "application"[1].  Owen appears
to agree from multiple different comments of his that I've read in
bugzilla.  The documentation should reflect this usage, and the window
manager should also be hinted about this grouping (so that
group_leader corresponds to GtkWindowGroup; Owen also agreed with
this).  The limiting effect of grabs should only be mentioned as one
of the possible side effects of grouping.  (For the curious: an
additional possible side effect is that window managers and pagers can
provide special functionality to act on all the windows of an
application -- e.g. moving all gimp windows to workspace 3).

* Types of modality *

Problem:
"application"-modal is the only type of modality implemented by gtk+,
but it isn't the only type of modality that exists.  There is also
parent-window-modal (more limited in scope) and process-modal (less
limited in scope).  Should these be implemented?

Possible motivation for other types:
Application authors are abusing GtkWindowGroup in an attempt to get
parent-window-modal behavior (see e.g. bug 307095).  That would seem
to suggest that it is wanted.  I really don't know why anyone would
want process-modal.  I can't think of a single use case.  It seems to
come up a fair amount, though.  Personally, I think the reason
process-modal probably comes up is that GtkWindowGroup is abused in an
attempt to get parent-window-modal behavior and then when
"application"-modal is needed it implementationally looks like
process-modal.  But I may have just missed something.

* Possible solutions *

For providing correct hints with "application"-modality:
 - add gtk_window_set_modal_to_entire_app(window), handling both modality
   and the hint
 - add gtk_window_set_transient_to_entire_app(window)
 - fix the documentation of gtk_window_set_modal() to mention
   gtk_window_set_transient_to_entire_app().

For GtkWindowGroup:
 - agree that Owen is right about intended purpose, document it
 - make the notes about grabs mention that it's only a side effect,
and that it's only
   one of the possible side effects
 - make group_leader hints correspond to GtkWindowGroup match

For different modality types:
 - if modal-to-parent is wanted, add gtk_window_set_modal_to(window, parent)
   which handles both the modality and the hint
 - decide that process-modal is bunk
 - deprecate gtk_window_set_modal() ?

Other:
 - Whine that metacity and libwnck are broken too.  :-)




So...  comments?  Thoughts?  Ideas?  Opinions?  Gossip?

Thanks,
Elijah


[1] Note that a process might have windows seen as belonging to
separate "applications".  One case of this is where a user launches
firefox twice and isn't aware that their two firefox windows are part
of the same process (because they are unaware of the single-process
trickery played by firefox).