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

[Diego Moya]

> 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.

Window in a container: maximize -> application covers all the group rectangle.
Window not in container: maximize -> application covers the full screen.

That's one reason why changing between wrapped/unwrapped quickly is important.


> 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?

One use case:

- Two main applications, with several supporting information apps (say
text files in Kate) that are secondary to the task.
- Mode A: I want to have all windows arranged on screen: create a Grid
container and tile all them.
- Mode B: I want to focus in the two main apps: "unwrap" the group.
The main apps occupy half the screen each, the supporting apps are
hidden behind.

Change between mode A and B as many times as you need, with just one
click. With the possibility to change anytime to a different task and
other applications, and go back to this group instantly by bringing
the wrapped/unwrapped group to the top again.


> 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...

The metaphor you're looking for is "layers in an image editing tool".


> 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 still prefer the modeless interface in my proposal. This would allow
the user to interleave unrelated actions between the initial container
creation and the later addition of other windows to it.

You would require two different buttons then, each with a consistent
meaning: one to "create new group" and one to "add window to  group",
where the group can be one of:
a) the last selected group (and the "add to group" button changes to
reflect its code color)
b) a dropdown showing all available groups.

This would also solve the problem of when to change adding to a new
group. Of course if only drag&drop is used, you can avoid "add window
to group" and have only the "create group" button. And it would still
be modeless.


>> 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"?
That's why I also suggested matching icons/emblems to go with the
color. The color coding is not to be acted upon, this is only as a
reminder, since the user created the groups herself on this session.
You destroy the group when the user explicitly closes it.


>>> 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.

Same here, the user created the groups, they have a meaning related to
the task for which apps where put together. With the constant
reminders of color and grouped taskbar, I don't think this would
create confusion. It's something to be tested, though.


>> I was thinking a "Grid" icon:
>> More visual, less abstract
>
> ...much harder to fit in ~8x8 pixels? ;-)

You haven't seen ZX Spectrum graphics, do you? :-P


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

One click is better than one drag&drop; two might be worse, except for
disabled users who can't do drags. So it depends on the target users.
For accessibility I'd say, go with a click-only interface if possible
- with drag & drop just as an accelerator.