Re: modality, hinting to the WM, and GtkWindowGroup

[Owen Taylor <otaylor redhat com>]

On Mon, 2006-05-01 at 17:13 -0600, Elijah Newren wrote:
> 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. 

Yes, I haven't fully tracked down all your arguments, but in
isolation:

 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. 

Is using me as an authority for something I don't agree with at all.
There is one sense it is true: I don't see a point in distinguishing
between:

 "Toplevel window and a set of related dialogs and auxiliary windows"

and

 "Application"

So, yes, I do believe that GtkWindowGroup is a natural candidate for
grouping a bunch of windows together into an "application". But I don't
see that as being meaningfully distinguished from something some other
concept of "modal to a window".

>  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. 

The reason that there is a bug open for process-modal was a direct
request from the Mozilla folks. The only use case for it I know of
is in error handling, but that's a least a minimal use case. 

Maybe its not needed. But its more motivated in my mind than the
distinction between modal-to-toplevel and modal-to-GtkWindowGroup.

>  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.  :-)

I don't want to get all abstract and metaphysical here, but to come
up with the right API changes (if any are needed), I think you have
to analyze the users point of view. What do they see? What is there
model of the situation?

The GIMP is some sort of pathological worst case where a bunch of
toplevel windows share dialogs, but it's almost completely non-modal -
the "Do you really want to quit with unsaved changes" dialog live
updates if you create new windows with it up.... so its not really
worth thinking about how modality relates to it. Most applications
are far more straightforward.

> > 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.

I really don't think bug 307095 has anything to do with this. Bug
307095 is the discussion of how to handle some sort of situation
where you have auxiliary windows that need to get events even when
a modal dialog is up, but where the modal dialog, the parent, and the
auxiliary window are *all* part of of a set of windows associated 
with a toplevel.

> 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.

It's hard really to know what was going on in bug 307095 ... it's all
expressed in really abstract terms. Maybe we just need to ask tberman
to explain what he was really trying to do... but the impression I
got was that C wasn't really a an independent toplevel, but some sort
of popup or tool window or something like that.

But C is in any case, not a "modal" window at all... a modal window
is a window that blocks the user interaction until the user deals
with it ... it establishes a "mode".

Regards,
					Owen