I have refreshed my memory a bit, and I'm preparing a branch for in git for this. There was already a windowstack3 so it will be nr 4 this time: branch rhialto/windowstack4. I'm squashing all 3 commits into one, since there is a reorganization along the way and that doesn't help with understanding the principles.
To summarize, from the commit message:
==========
A windowring that behaves like a stack.
Based on the following observations:
- The difference between a window ring and a stack is effective at
the moment the modifier key is released.
- at modifier-down time, we remember the "bottom of the stack".
- at modifier-up time, we move window we moved to (if any) to the top
of the stack.
- So if we can do some administrative work both when the modifier is pressed
and when it is released, we can make a ring into a stack.
- We can already make bindings for pure modifier keys.
- All current bindings are for key-down events.
- We can make bindings for key-up events if we pretend this is a new modifier.
RingLeader can change if we enter or leave windows. That would rotate
the stack. Therefore we designate "Scr->Ring" as a fixed point to start
every time.
"Tab" = m4 : all : f.warpring "next"
"Tab" = m4 | s : all : f.warpring "prev"
"Return" = m4 : all : f.ring
"Super_L" = : all : f.warpring "startstack"
"Super_L" = up | m4 : all : f.warpring "finishstack"
==========
Previously, all key mappings were on key-down events. This adds possible
mappings for key-up events too, since we use one here.
Which is kind of one of the weak points. The whole thing depends on
several key mappings to exist and be consistent. It is easier to get it
wrong than for many other settings.
So the 'f.warpring "startstack"' sets up some administration, and the
'f.warpring "finishstack"' reorders the windows in the window ring such
that the effect is a stack.
So this only works if you're using Alt-Tab, or at least some mapping
that includes a modifier. The modifier must be kept pressed the whole
time, until the right window has been reached, and then it must be
released. You can't map this to, say, plain F4. ctwm would not know if 2
presses of F4 means that you want to move 2 windows down the stack, or 2
times 1 window (the latter interpretation would get you back to the
starting state).
Maybe this isn't such a problem. Other window stacks (like MacOS or
xfce) also work like that. But they have a lot of visual feeback, and we
just have windows that get popped to the front.
It would be nice if we could somehow incrementally work on the changes
in the window ring. In that case, the clean-up at the end would not be
needed. But I didn't find a way back then, and it seems implausible.
Illustration: suppose the window ring contains these windows, with ^
under the active one:
1 2 3 4 5
^
and now you press Alt-Tab 3 times, so window 4 becomes the active one:
1 2 3 4 5
^
If this is when you release the Alt key, this gets reordered so that
window 4 is moved to the front:
4 1 2 3 5
^
so that the next time you press Alt-Tab once, you get back to the
previously active window nr 1. Suppose we do 3 Alt-Tabs again:
4 1 2 3 5
^
and then it becomes
3 4 1 2 5
^
so now it requires 2 Alt-Tabs to get back to window 1.
If there is a way to have the stack up-to-date after every single
Alt-Tab, without requiring action when Alt is released, that would be
great. But I fear you *have* to know when the user is done; otherwise
you have the ambiguity of the meaning of 2 Alt-Tabs in a row (like the
F4 example above).
-Olaf.
--
___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl>
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
