Re: modality, hinting to the WM, and GtkWindowGroup
- From: Owen Taylor <otaylor redhat com>
- To: Elijah Newren <newren gmail com>
- Cc: GTK+ development mailing list <gtk-devel-list gnome org>
- Subject: Re: modality, hinting to the WM, and GtkWindowGroup
- Date: Mon, 01 May 2006 18:19:21 -0400
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]