Re: modality, hinting to the WM, and GtkWindowGroup

["Elijah Newren" <newren gmail com>]

On 5/1/06, Owen Taylor <otaylor redhat com> wrote:
> I'm not really sure what I thought in the past. But I do not
> agree now.

If you don't know what you thought in the past, how do you know
whether you agree with it or not?  ;-)

> You seem to want to have:
>
>  A) Modal to process
>  B) Modal to "application" (WindowGroup)
>  C) Modal to parent

You must have only had time to skim what I wrote, which is
understandable.  Unfortunately, it has resulted in a view which is not
correct; your summary does not reflect what I want.  Let me re-quote a
small part of what I said before (with some extra emphasis):
 - *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
which came from the section titled 'possible solutions'.

What I really want is
 A) make sure the WM has the needed hints for whatever is decided
    (for reference, note that the EWMH specifies how to hint
    modal-to-parent and modal-to-group)
 B) mention related issues and help fix them if wanted/needed
as part of an effort to fix modality/transiency issues in libwnck,
metacity, gtk+, and applications.

> This is too much, and too complex, and I know of no use case where
> an app wants all 3 of these. I know of no user who could figure out what
> the heck was going on if an app did have all three.

I agree (see above).  However, you didn't state whether you felt the
same way about having just two of these, namely modal-to-group and
modal-to-parent.  I wasn't sure whether two would be warranted or
wanted, but just brought it up for completeness.  If you don't like
the idea of having two, that's perfectly fine.  But I'd really
appreciate comments on the other part of my email.  :-)

> GtkWindowGroup was meant to be a flexible abstraction, but the only
> thing I had in mind was "modal to parent" case, which was the request
> I was trying to accommodate.

When someone did exactly this and submitted a patch to add
documentation to gtk+ to make it easier for others to understand how
to do it, you said it was not the correct use of GtkWindowGroup and
rejected the patch.  See bug 307095 for the details.  Further, you
said that having "applications" be a grouping of windows different
than GtkWindowGroup would also introduce too much complexity.  See bug
59724.  I agree with the comments you made in those two bugs and think
using GtkWindowGroup to handle modal-to-parent would be bad.

Food for thought:
Something I just thought of.  I had been thinking of modal-to-parent
as a way to correctly fix bug 307095.  However, looking at that bug, I
think it's really weird to have B modal to C when C is transient to B.
Maybe there's a fix somewhere to make sure modality only pertains to
the subset of the group perceived as ancestors?  With something like
that, modal-to-group wouldn't have any shortcomings that I'm aware of
and would remove the need for modal-to-parent behavior as far as I can
tell.  Also, if it's not done that way, I don't see how the WM can
figure out what the modal window is and what it is modal to.


Thanks for the comments,
Elijah