Re: [Usability] Metacity Proposal: Grouping Windows



On Sun, 2004-03-07 at 16:27 +0100, Reinout van Schouwen wrote:
> Ryan,
> 
> I'm not quite convinced yet that a new parent window for the grouped
> windows is a good idea. Did you ever try to make a screenshot of your
> desktop, then opening it in an image viewer? Don't tell me you weren't
> confused!
> 
> So could you elaborate a bit more on how focus issues would be handled.
> (Would the new parent window have a title bar and all? Is it maximizable?
> Do the child windows have title bars, and are they focusable?)

I threw together a very dirty mock up using GIMP as an example. Right
now GIMP does some non-trivial work to get its window management in
order. IMO this is hacking to get around Metacity's failures, so my
solution may not be the right one, but its worth examining how we can
get Metacity to do its job.

http://www.cpsc.ucalgary.ca/~ryanm/mockup.png

Heres the scenario: We have multiple windows open which we want to treat
both as a group and as individuals. This makes sense about how we
imagine other things: I can say "get me my pencil-box", or I can say
"get me pencils A, and B"; I don't have to enumerate pencils A to G
individually as separate and distinct entities.

	In my proposal the parent window behaves exactly as a current window
behaves, so the only case to consider is how sub-windows behave in such
a group: 

When the parent minimizes, all sub-windows minimize. When the parent
moves, all sub-windows move similarly such that their relationship to
the parent and other sub-windows doesn't change. When the parent rolls
up the sub-windows minimize.

When the parent is resized by (x%, y%) all sub-windows get resized
proportionally (x%, y%). When the parent is maximized, we might have to
treat this as a "maximum resize" of the parent, so that sub-windows
retain their relationship with the other sub-windows.

In my proposal I described how minimizing sub-windows can't actually
minimize, since this makes windows disappear, and thus break their
membership with the group, so we re-define minimize/unminimize as roll-
up/unroll-up. We redefine maximizing sub-windows as only taking up the
whole parent window, not the whole screen. This behaviour makes sense if
you consider X's root window as the parent window. 

The close button can be thought of as eliminating ones self from the
group, and then from all other parent windows, including the "global"
group (ie it quits).

Resizing, or moving a sub-window should be independent of any other sub-
windows. However, it cannot be independent of the parent window, that
is, it cannot be resized large than the parent, not can it be moved
outside the parent. 

If one wants to disassociate a sub-window from the parent, its needs to
dismantle the group, or resign from the group individually.

Focus is hierarchical, that is a sub-window cannot have focus unless the
parent has focus. Similarly having focus on a sub-window implies that
the parent has focus. Lets assume "Focus-on-click" for simplicity:
Clicking on a parent gives no child focus, however clicking on a sub-
windows automatically gives the parent "focus".

I think that Focus might be where my idea introduces the most complexity
in the UI. I don't use keyboard or accessibility navigation modes often
enough to understand the ramifications such a focus scheme. However I am
hopeful that my ideas are intuitive enough that they will work in the
long run.

Any more comments, questions, or ideas? Keep em coming!

Cheers,
Ryan




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