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 >
