Re: windowstack2
Vitaly Shevtsov <[email protected]> Tue, 26 Aug 2025 21:38:46 +0500
| Newsgroups | gmane.comp.window-managers.ctwm |
|---|---|
| Message-ID | <CAKydt3aYsU9+sZvDzQuvvT4KzVfsB4z7xiUpRL7R72_WT1ChAg@mail.gmail.com> |
--0000000000000367a7063d474f8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Great! Looking forward to this :) =D0=B2=D1=82, 26 =D0=B0=D0=B2=D0=B3. 2025 =D0=B3., 21:37 Rhialto <rhialto@f= alu.nl>: > 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: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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" =3D m4 : all : f.warpring "next" > "Tab" =3D m4 | s : all : f.warpring "prev" > "Return" =3D m4 : all : f.ring > > "Super_L" =3D : all : f.warpring "startstack" > "Super_L" =3D up | m4 : all : f.warpring "finishstack" > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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. Ros= e > --0000000000000367a7063d474f8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Great! Looking forward to this :)=C2=A0</div><br><div cla= ss=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_at= tr">=D0=B2=D1=82, 26 =D0=B0=D0=B2=D0=B3. 2025 =D0=B3., 21:37 Rhialto <<a= href=3D"mailto:[email protected]">[email protected]</a>>:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex">I have refreshed my memory a bit, and I'm prepar= ing a branch for in git<br> for this. There was already a windowstack3 so it will be nr 4 this time:<br= > branch rhialto/windowstack4.=C2=A0 I'm squashing all 3 commits into one= ,<br> since there is a reorganization along the way and that doesn't help wit= h<br> understanding the principles.<br> <br> To summarize, from the commit message:<br> <br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> A windowring that behaves like a stack.<br> <br> Based on the following observations:<br> <br> - The difference between a window ring and a stack is effective at<br> =C2=A0 the moment the modifier key is released.<br> =C2=A0 - at modifier-down time, we remember the "bottom of the stack&q= uot;.<br> =C2=A0 - at modifier-up time, we move window we moved to (if any) to the to= p<br> =C2=A0 =C2=A0 of the stack.<br> - So if we can do some administrative work both when the modifier is presse= d<br> =C2=A0 and when it is released, we can make a ring into a stack.<br> - We can already make bindings for pure modifier keys.<br> - All current bindings are for key-down events.<br> - We can make bindings for key-up events if we pretend this is a new modifi= er.<br> <br> RingLeader can change if we enter or leave windows. That would rotate<br> the stack. Therefore we designate "Scr->Ring" as a fixed point= to start<br> every time.<br> <br> "Tab" =3D m4 : all : f.warpring "next"<br> "Tab" =3D m4 | s : all : f.warpring "prev"<br> "Return" =3D m4 : all : f.ring<br> <br> "Super_L" =3D : all : f.warpring "startstack"<br> "Super_L" =3D up | m4 : all : f.warpring "finishstack"<= br> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br> <br> Previously, all key mappings were on key-down events. This adds possible<br= > mappings for key-up events too, since we use one here.<br> <br> Which is kind of one of the weak points. The whole thing depends on<br> several key mappings to exist and be consistent. It is easier to get it<br> wrong than for many other settings.<br> <br> So the 'f.warpring "startstack"' sets up some administrat= ion, and the<br> 'f.warpring "finishstack"' reorders the windows in the wi= ndow ring such<br> that the effect is a stack.<br> <br> So this only works if you're using Alt-Tab, or at least some mapping<br= > that includes a modifier. The modifier must be kept pressed the whole<br> time, until the right window has been reached, and then it must be<br> released. You can't map this to, say, plain F4. ctwm would not know if = 2<br> presses of F4 means that you want to move 2 windows down the stack, or 2<br= > times 1 window (the latter interpretation would get you back to the<br> starting state).<br> <br> Maybe this isn't such a problem. Other window stacks (like MacOS or<br> xfce) also work like that. But they have a lot of visual feeback, and we<br= > just have windows that get popped to the front.<br> <br> It would be nice if we could somehow incrementally work on the changes<br> in the window ring. In that case, the clean-up at the end would not be<br> needed. But I didn't find a way back then, and it seems implausible.<br= > <br> Illustration: suppose the window ring contains these windows, with ^<br> under the active one:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 2 3 4 5<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^<br> and now you press Alt-Tab 3 times, so window 4 becomes the active one:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 2 3 4 5<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^<br> If this is when you release the Alt key, this gets reordered so that<br> window 4 is moved to the front:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 4 1 2 3 5<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^<br> so that the next time you press Alt-Tab once, you get back to the<br> previously active window nr 1. Suppose we do 3 Alt-Tabs again:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 4 1 2 3 5<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^<br> and then it becomes<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 4 1 2 5<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^<br> <br> so now it requires 2 Alt-Tabs to get back to window 1.<br> <br> If there is a way to have the stack up-to-date after every single<br> Alt-Tab, without requiring action when Alt is released, that would be<br> great. But I fear you *have* to know when the user is done; otherwise<br> you have the ambiguity of the meaning of 2 Alt-Tabs in a row (like the<br> F4 example above).<br> <br> -Olaf.<br> -- <br> ___ Olaf 'Rhialto' Seibert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <rhialto/at/<a = href=3D"http://falu.nl" rel=3D"noreferrer noreferrer" target=3D"_blank">fal= u.nl</a>><br> \X/ There is no AI. There is just someone else's work.=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0--I. Rose<br> </blockquote></div> --0000000000000367a7063d474f8d--