Hello again :)
Rhialto, I see you created windowstack4 branch, thank you.
But I found it works better with this patch:
diff --git a/functions_warp.c b/functions_warp.c
index cc2e41ad..4ce763ec 100644
--- a/functions_warp.c
+++ b/functions_warp.c
@@ -330,15 +330,6 @@ FinishWindowStack(void)
Scr->BottomOfStack = NULL;
return;
}
- /*
- * If the window to move is already where we want to move it,
- * there is nothing to do. Probably due to not enough windows.
- */
- if(Scr->BottomOfStack->ring.prev == tomove) {
- printf("RingLeader already before BottomOfStack\n");
- Scr->BottomOfStack = NULL;
- return;
- }
Without these changes, I cannot switch between two last focused
windows with alt + tab + release alt.
But with this patch it works, but sometimes it alt+tab switches to a
current window. I haven't figured this out yet.
On Tue, Aug 26, 2025 at 9:38 PM Vitaly Shevtsov <[email protected]> wrote:
>
> Great! Looking forward to this :)
>
> вт, 26 авг. 2025 г., 21:37 Rhialto <[email protected]>:
>>
>> 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
