Re: modality, hinting to the WM, and GtkWindowGroup

[Owen Taylor <otaylor redhat com>]

On Mon, 2006-05-01 at 13:18 -0600, Elijah Newren wrote:
> * Documentation and meaning of GtkWindowGroup *
> 
> Problem:
> GtkWindowGroup is poorly documented.  It is also abused/misused. 
> There may even be some arguing about what it should mean, though that
> may just be due to its poor documentation.
> 
> Solution:
> 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.  The documentation should reflect this usage, and the window
> manager should also be hinted about this grouping (so that
> group_leader corresponds to GtkWindowGroup; Owen also agreed with
> this).  The limiting effect of grabs should only be mentioned as one
> of the possible side effects of grouping.  (For the curious: an
> additional possible side effect is that window managers and pagers can
> provide special functionality to act on all the windows of an
> application -- e.g. moving all gimp windows to workspace 3).

I'm not really sure what I thought in the past. But I do not
agree now.

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

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.

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.

						Owen