Fwd: Adding "group/split" button to the decoration

[Matthew Woehlke]

Diego Moya wrote:
> 2009/7/8 Matthew Woehlke wrote:
>> What about (in addition to above) a button to wrap a window in a new
>> container? It could be a dropdown for container type and also include
>> option to interactively create container.
> 
> Two questions to assess quality:
> 
> - How many clicks to use?

- One or two to select container type (just like any menu, you can 
click+drag, or click twice)
- If using interactive group, one per window, plus one (or a keystroke) 
to indicate you are done

> - Does the user have to remember the current "state"? I.e. after
> pressing the first button, if I do anything else than press the second
> button, operation is canceled. AND there's no visual clue of this.

No. You'd be in a "pick windows" mode that would be obviously different 
from 'normal working' mode. (With composite, probably something like 
expose mode.) If you cancel, you cancel and have to start over, there 
wouldn't be any "unexpected behavior".

>> I'm not sure about this, it makes sense, but how do you know when to
>> 'forget' the virtual group? Otherwise I think there is a very large risk
>> for confusion if time passes between ungroup and regroup.
> 
> Just color-code windows pertaining to the same group, or add some
> other visual reminder (same icon).

Hmm... maybe. Though color coding is difficult (a11y problems at 
minimum, possibly u7y problems as well). When do you forget a "virtual 
group"?

> I was thinking a "Grid" icon:
> 
> ------------
> |       |  |
> |       |  |
> |       |--|
> |       |  |
> ------------
> 
> More visual, less abstract

...much harder to fit in ~8x8 pixels? ;-)

> But your Wrap/unwrap icon has the advantage to work for all kind of
> containers.

True.

> Other advantages & disadvantages?

Well it's deco-specific anyway, so not worth too much discussion :-). 
Not at this point, anyway.

> 2009/7/8 Maciej Pilichowski:
>> On Wednesday 08 July 2009 00:26:03 Matthew Woehlke wrote:
>>> Or would this be a button on a
>>> container to absorb a window (with second click)?
>> Exactly.
> 
> - Does the user have to remember the current "state"?  (Clicking
> anywhere than on the second window cancels the operation, and there's
> not a visual clue of this mode)

There should be some obvious visual indicator of what is happening.

> - How many clicks to use?

Two: click button, click window to absorb. (Hmm, but now I wonder how 
this is better than just drag-and-drop?)

> Ok, forget about virtual desktops. Let's refine current approach:
> 
> -1st window. Press "groupize" icon. It creates a grid container about
> 1st window, with a "hollow application" as a remainder of grid
> creation an instructions on how to add a second one.
> - 2nd window. Press "groupize" icon, app gets added to the hollow
> application hole.

How does the WM know I didn't want to start creating a second group?

The previous proposal was one action to say "I am going to make a 
container", one click per window, one action to say "okay, I am done for 
now". I don't see a problem doing this in a way you have an initial 
window. That's only one more action than your suggestion, without the 
ambiguity. Would that be satisfactory?

> - 3rd, 4th, 8th windows... added to the container with one click each.

You know you can also do this with drag-and-drop... :-)

> Their decorations all get the same color.
> - To split one window from the container, press its

Hmm, "tear off" button... don't think that came up yet, think I like it...

> - To split all windows in the container, press the container's "split"
> button. Windows get free, but remain color-coded.
> - To group all 8 windows again, press any of their "group" icons.
> - To destroy the container in a permanent way, press its "close"
> button. Windows get free and lose their color coding.

Hmm, so you are thinking something like... hmm, how to describe it, a 
container type where the children float above it. Actually... I think 
this would work best as an actual container type. Sort of FAI but not 
keeping the windows inside it. Still not sure it's a good idea :-), but...

(That would have the advantage that everything still shows up e.g. in 
task switchers as grouped, still behaves as grouped, etc., which seems 
to be what you want. But can be moved around as if not grouped.)

...which makes me realize, I guess 'move to desktop' removes windows 
from containers. (Well... which it would, because you're moving the 
window to a different parent, since a desktop is just a parent. The 
alternative is to disallow it for windows in containers.)

>> What about "virtual groups", do you think that is a good idea or not? I
>> lean toward "not", seems like it has potential to be confusing. (Well,
>> unless implemented as 'undo WM action' ;-).)
> 
> I think it's a good idea because it allows you to split-regroup all
> windows with a single click, just like a maximize-restore operation.
> This is useful to switch focus between just one app and all apps in
> the group.

Hmm. Okay, don't know if we thought about maximize/minimize before. Not 
sure how to manage it for minimize in GAI, but for maximize I think it 
makes sense to make it sort of ZUI; maximize child makes it fill the 
containers (maybe with option that it should maximize container also, if 
not), restore obviously undoes that.

So... my question is, what do I get from splitting that I don't get from 
just maximize? (Or maybe full-screen?) If I want to focus on one app, I 
can just maximize/full-screen. If I want to rearrange, why do I need to 
break container to do that? (Let's assume it isn't because rearranging 
container is "too hard" in-place; doing it for that reason would be 
treating symptom without addressing problem.) Especially what benefit is 
there vs. making container FAI?

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
.sig omitted due to budget cuts.