Problem description:

The handling of modal dialogs provided by gtk+ is somewhat problematic; there are multiple cases where users will wonder why their "application stopped working".  This "stopped working" behavior is basically where the user observes a window getting focus which doesn't respond to input -- which can be even worse in special cases because the user might not even be aware of the existence of the dialog which happens to be modal (due to it being hidden below the window they are trying to type in as in bug #307875, or due to it being on a different workspace as in bug #312338).  This is due to incorrect hinting of modality-type to the WM.  It can affect not only focus, but also cause issues with stacking and even placement of the windows as well.


Details, details:

The main problem 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-group 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, e.g.
  gdk_window_set_transient_for (GTK_WIDGET (dialog)->window,
                                gdk_screen_get_root_window (screen));

In most cases there's only two application windows anyway (the main window and the dialog which is modal to it), so this hasn't seemed like a big deal previously.  But it does keep on coming up and should really be fixed.  I'm volunteering.  :-) Of course, since metacity doesn't yet recognize or support modal-to-group hints (see bug 126489), it needs to be fixed too and should be fixed first.  I've been putting all these issues off for like a year or two, but now seems like a good time to finally fix them all.  And of course, I needed to start with finally filing this bug since I've forgotten and put it off so many times.  ;)


Possible solution:

I'm thinking something along the lines of adding
  gtk_window_set_modal_to_entire_app()
  gtk_window_set_modal_to_parent()
and deprecating gtk_window_set_modal().  The reason for the first new function should be clear from this bug report, I hope.  The reason for the latter is covered more in bug 340166 (though also the fact that it is explicitly spelled out how to handle in the EWMH).  The latter, however, would need the gtk's grab system to be extended to somehow handle making the window only be modal to one other window.  Anyway, would these two functions seem reasonable?  Alternative suggestions or comments?  Ideas on implementing modal-to-parent-window behavior?


Related bugs:

This bug has basically already been filed as both bug 124525 and bug 91023 (and maybe others?).  It is very similar to bug 59724, bug 69934, bug 109638, and bug 307095, though all of these are more on the topic of process-modal vs. "application"-modal vs. parent-window-modal.  See bug 340166 for an explanation tying these gtk+ bugs together.  Outside of gtk+, there's also bug 126489 against metacity (and its dupes) and bug 338013 (and bug 310381) against libwnck for handling of modal-to-group dialogs.  See also http://mail.gnome.org/archives/wm-spec-list/2006-March/msg00001.html.