WM: grouping applications (TAI)

Matthew Woehlke mw_triad at users.sourceforge.net
Mon Mar 9 16:13:29 CET 2009


Maciej Pilichowski wrote:
> On Thursday 05 March 2009 22:44:10 Matthew Woehlke wrote:
>>> Btw. I use win-right/ctrl-tab, win-left/shift-ctrl-tab for tab
>>> switching.
>> If these are indeed unbound (as they seem to be) in default
>> configurations, I'd agree.
> 
> Ok, however I just said _I_ use them, no need to go public with 
> those :-)

Why not? I think we need *something*, and the above is pretty much the 
same idea I came up with.

>>> For example -- you have GAI in TAI in GAI in TAI in GAI... -- how
>>> do you window-switch in such case?
>> Child-switch is limited to windows in the parent. 
> 
> Ok, direct children?

Let me try again. Let's say you have (easy example):

(a) tile container +
   (b) tab container
     (c-f) konq's (with qt doc)
     (g-i) konsole (h+)
   (k) kate sidebar +
   (l) tab container
    (m-p) kate documents (with various source files) (n+)
(q) kpat

Now, each parent (including root) has a last-active child, right? So the 
active window is defined as:
1. start at root's active child
2. if the child is a window, done
3. otherwise take the child's active child and go back to step 2

The '+' mark active children, above. So right now "k" is the active 
window. Root-switch (alt-tab) would switch between "a" and "q" (i.e. 
would show switching to "a", so whatever name that container has, 
previews would show the whole container, etc.). Sibling-switch while "k" 
is active will switch between "b", "k" and "l". Once you switch to "b", 
"h" becomes the active window and sibling-switch would instead switch 
between "c" through "i". So you do need a navigation mode that lets you 
go back to the parent, and probably you should have one that goes down 
into the children, e.g. so you could get from "k" to "f" with 'left', 
'down', 'left', 'left'.

>> I can imagine something like cover switch with multiple rows; the
>> bottom row is siblings, above and center is the parent, and next to
>> that are the parent's siblings. If desired it could go all the way
>> up to the root's children, or show just one parent row (if there is
>> a non-root parent).
> 
> Here I am lost. Let's back to your example, I am writing something in 
> any doc within Kate, Konq. is visible, I would like to make a switch 
> to Konsole. How we do this.

Assuming you have the awesome plug-in :-). You press ctrl-tab. Up pops 
something with these preview images:

[k]    [l]    [b]
[n] -->[o]<-- [p]
   (empty space)

("m" is probably there also, "in the background", either falling off an 
edge of the screen, behind "n" or "p" and faded out a bit, or whatever, 
depending on the exact effect.)

You were on "n", but you've switched to "o" without thinking how that 
isn't what you really want to do. So you hit 'up', 'right'; now you see 
this:

[q]    [a]
[l] -->[b]<-- [k]
[g]    [h]    [i]

If you wanted to get to "i", you could either 'down', 'right', or let go 
of the modifier and tap ctrl-tab.

> For the last one I can think of something like visual switching -- you 
> activate switch with (all keys are just examples) F7. Then you switch 
> the same level objects (windows or containers) with tab/shift+tab or 
> faster (visual way) with arrow keys. Escape to cancel switch. Enter 
> or F7 again accept the final switch. Space to go one level down, 
> shift+space to go one level up.

That's roughly what I'm describing, except I wouldn't use a key to 
change modes... just make it like alt-tab; the first key puts you in 
switch mode, you leave when you let go of the modifier key. Until you 
do, you can move around with arrows/etc. (I think I would want to use 
mainly arrows, not so much space/whatever, though tab/shift-tab is okay.)

I suppose there isn't any reason you couldn't /also/ do an activation 
key, I'm just not convinced it's needed.

>>> 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?
>> Slightly worse than doing it with TDI? ;-)
> 
> Ok, but since you provided the proof of mixed mode need we have to 
> think about it. I would like to detach one of the TAI window, and 
> this TAI is already in GAI. What happens? It goes directly to the 
> desktop? Or it goes to GAI container?

I think my earlier suggestion was it tries to go in the deepest 
container possible, unless you do something that makes it go to root 
instead (or vice-versa), where "something" is e.g. hold ctrl.

Obviously there should be visual feedback as to what is happening :-).

>>> New issues :-) For TAI, should container from top to bottom
>>> should look like:
>> ...I could agree here also. I think I prefer to make it
>> configurable, which reduces the question to "which is default";
>> that's easier to answer (and dead simple to change).
> 
> Ok then, however all in all I would prefer menu/tabs order because it 
> is more consistent for future uses, when we would shift to 
> philosophy "everything is browser", so we need URL editbox. Which 
> would be more sane to have menu/URL/tabs. Or maybe not sane, but I am 
> used to it because of Konqueror ;-).

That... might be interesting :-). Again I'm more inclined to copy chrome 
'tabs above everything' since it fits more with the tab as a WM object 
concept (and is less technically challenging).

Um. Actually, that might be the way that it has to happen first; come to 
think of it I'm not sure menu-on-top is possible without menu 
redirection ala the 'OS-X style menus' stuff. Which people are going to 
want anyway ;-), but as a first run...

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
"You know what Microsoft's problem really is? They've lost the ability 
to feel ashamed." -- Pamela Jones (Groklaw)



More information about the Kde-usability-devel mailing list