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

[Matthew Woehlke]

Diego Moya wrote:
>> 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.

I was thinking about that... but why not just maximize the container in 
that case? Same number of clicks...

(I'd even be okay with an option that maximize a child *does* maximize 
the container as well. Then it is only one click :-).)

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

Or you could lay out the apps as follows:

GAI 1
   GAI 2
     Main app A
     Main app B
   ...supporting apps in GAI 1...

(or whatever containers are most appropriate...)

So you maximize/restore container 2. Same effect, no? And A+B are still 
in a container.

With yours you have maybe slight advantage because the above can't give 
you free-floating apps in "focus" mode without more work, but you also 
have possibility that focus is wrong. I'm not sure if it's worth it, but 
at any rate you can still do it with "DAI" container type (FAI but 
without the geometric container; apps in DAI container behave as if 
dialogs, always).

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

...except your proposal /isn't/ modeless, you are always in mode of 
having to remember what container "add" will add to :-).

> This would allow
> the user to interleave unrelated actions between the initial container
> creation and the later addition of other windows to it.

...which you can do by drag-and-drop, or by reactivating 'add windows' 
mode. Only difference is you explicitly say "I am done adding windows".

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

I am concerned that your proposal requires visual identification of 
containers. Icons are small and hard to see. Colors are not accessible; 
for people with limited color vision, it is very difficult to have more 
than a handful of readily identifiable colors. (Even with full color 
vision, more than about six is getting problematic, and that's not very 
many.)

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

So is d&d enough for you? Because we definitely intend to have d&d :-). 
(With also 'click group, click window' for those that want/need it.)

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

Yes, good point.

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