Re: modality, hinting to the WM, and GtkWindowGroup

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

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

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



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.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]