Re: modality, hinting to the WM, and GtkWindowGroup

["Elijah Newren" <newren gmail com>]

On 5/1/06, Owen Taylor <otaylor redhat com> wrote:
> On Mon, 2006-05-01 at 17:13 -0600, Elijah Newren wrote:

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

Maybe I'm misunderstanding you, but that sounds like a rephrasing of
what I said, and that you do agree after all.  Is that right, or am I
missing something?  If the latter, did I misinterpret what you
originally said in bug 307095 and bug 59724 too?

> But I don't see that as being meaningfully distinguished from something some other
> concept of "modal to a window".

I'm not quite following.  Are you saying that you believe the only
form of modality worth implementing is modal-to-GtkWindowGroup, or
that GtkWindowGroup should never include more than two windows, or
something else?

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

Okay, so you don't see the need for both modal-to-toplevel and
modal-to-GtkWindowGroup.  I hope this isn't a dumb question you've
already answered, but I've had a hard time understanding your
responses so far, so let me ask to see if I'm getting on the same page
yet:  Which of the two do you think should be implemented?

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

Yes, they explictly mention that all the windows are associated, and
namely that it's a grandparent-parent-child relationship (which better
imply that they're all part of the same "application" as well). 
That's exactly why I thought that bug was relevant to the discussion.

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

Well, they did explicitly state that C was related (transient to one
of the other windows) and thus not an independent toplevel.  So, I can
easily see where you got that impression from.  ;-)

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

Right, I never claimed that C was modal; nor did they.  The problem
was that C was a window being blocked by the modality of B when the
modality of B should only apply to A.  That's why I brought it up and
why it was related to the whole discussion.


Thanks,
Elijah