WM: grouping applications (TAI)

[Maciej Pilichowski]

On Thursday 05 March 2009 00:24:59 Matthew Woehlke wrote:

  I start from stupid question ;-)

> Please do not quote my e-mail address unobfuscated in message
> bodies.

It does not bother me at all since I have another template set 
(without email), but you do realize your address is on the plate in 
your mail?

> > a) let's say you already have organized TAI, something similar to
> > Konq. TDI but each tab is distinct app, no other app is running
> > -- is task switching is possible via the same alt+tab as usual?
> > Or should switching within tab should be distinct from "normal"
> > task switching?
>
> In short, it's a good question that needs an answer. Perhaps best
> is to us alt-arrows for tree navigation, and alt-tab to switch only
> top-level windows/containers 

OK, I was focused on is it or not possible to use alt-tab for that 
switching, so we agree. Alt-tab should be reserved only for first 
class windows/containers. 

Another matter is switching windows within containers, but whatever 
shortcut we choose as default it is not related (as long it is not 
alt-tab) to the above. 

Btw. I use win-right/ctrl-tab, win-left/shift-ctrl-tab for tab 
switching.

> > b) can GAI container can be put (I ignore for the moment _how_)
> > into TAI?
> >
> > c) can TAI container can be put into GAI?
>
> Yes and yes. 

:-)

>  From a technical standpoint, a group (which can be floating
> windows, recall) should be generic.

I was more inclined to user POV. What do we need for such elaborate 
mechanism.

>  From a technical standpoint, my answer is a very emphatic "yes".
> From a usage standpoint, I'm more inclined to take a wait-and-see
> attitude; 

Exactly ;-) I mean I can hardly foresee any usage of it. I found 
several but they are other cases -- main window + toolboxes. Example 
Gimp -- one main GAI container, left window painting tools. The right 
window -- TDI container with images per each tab.

This is the most sophisticated, and usable at the same time, example 
as I can see. But it is _one_ app. So it does not apply here (or does 
it?).

> although I'll mention again that I don't
> like artificial limits :-).

I understand you, and I also don't like the limits. But we have one 
limit we have to think of -- UI. You can organize very complex data 
structures in code, but managing them by user is another matter.

For example -- you have GAI in TAI in GAI in TAI in GAI... -- how do 
you window-switch in such case? Is it possible to drag&drop window 
from one GAI to another GAI? If yes, how fast it would be possible to 
make a mess by accident?

I think here it would be better to provide basic TAI and GAI and see 
how it works. Maybe this simplicity will be advantage (similar to 
simplicity of ipod).

So I opt for ability to embedded container in container, but the 
moment you do it, the embedded container dissolve. So the structure 
would be flat. 

New issues :-) For TAI, should container from top to bottom should 
look like:

======== menu ===============
======== tabs ================

or reverse.

On the first sight the first one is more useful, because of the 
similarity to Konqueror. But on the second thought -- there would be 
problem with changing menus.

But then again, with TAI implemented TDI should be just special case 
of TAI. And with TDI the first layout is much better.

I just wrote the concerns, I think despite changing menu, the first 
one is the one to go.

> > PS. All I can say for the time that passed, that I miss GAI for
> > sure ;-)
> Yeah. Heck, just a tiling WM would be nice... but of course I don't
> want *only* a tiling WM (and the grouping part of GAI, i.e. groups
> are raised/lowered as one, would be nice also).

Oh yes :-)

Cheers,