Re: ratpoison gets confused about what is the active frame
Ian Hickson <[email protected]> Thu, 8 Apr 2021 15:36:26 -0700
| Newsgroups | gmane.comp.window-managers.ratpoison.devel |
|---|---|
| Message-ID | <CAP2znoZgHPLsJ_gPTH9K7P_Shyt4hvzS4dk73W_d4DPQdYivGw@mail.gmail.com> |
--000000000000287da605bf7daedc Content-Type: text/plain; charset="UTF-8" On Sun, Apr 4, 2021 at 1:11 PM Ian Hickson <[email protected]> wrote: > On Sun, Apr 4, 2021 at 2:41 AM Axel Svensson <[email protected]> > wrote: > >> On Sun, Apr 4, 2021 at 4:08 AM Ian Hickson <[email protected]> wrote: >> > There's a bug I run into sometimes that I can't quite reliably >> > reproduce, >> >> Reproducing it is your first problem. Try adjusting your configuration >> with: >> >> set border 3 >> set fwcolor "#a00000" >> set bwcolor "#0000d0" >> >> The above will help you double-check what frames ratpoison considers >> active/inactive/empty. >> > > I've added those, I'll report back if it helps with figuring out what's > going on. > For what it's worth, I just experienced this again. I think the last thing that I'd done in ratpoison other than change focus was resize a frame, though that was a while ago. The window that has keyboard focus is the one in the frame with the fwcolor border. When I press the key for "prev" or "next", the frame that I most recently resized is the one that gets its window changed, though the "Current Frame" message appears over the window that is focused, not the one that got changed. Resizing other frames doesn't affect the behaviour, it continues to be that same frame that gets the window changed. Using "exchangeleft" et al doesn't affect this. Using "only" followed by "undo" doesn't fix it. After using "only" to cause there to be only one frame, "prev" and "next" do affect that frame. After splitting the frame with "hsplit", it's the frame on the right that flips through the windows, not the frame on the left, regardless of which has the "fwcolor" border. (Interestingly, the list of windows flipped through does change based on which one has the "fwcolor" border and focus.) If I start from the state that's broken, then split the focused window ("hsplit" does seem to affect the frame one would expect it to affect), then it gets into a weird state where if the frame that was stealing prev/next earlier is focused, or if a frame near it is focused, then it gets the "prev"/"next" action, but otherwise the newly created frame flips through available windows. Using "remove" to remove all frames then resplitting everything seems to fix the problem. I'll keep trying to figure out how to trigger this. It's not like resizing always triggers it. Cheers, -- Ian Hickson --000000000000287da605bf7daedc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Sun, Apr 4, 2021 at 1:11 PM Ian Hickso= n <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br></div>= <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= "><div dir=3D"ltr"><div dir=3D"ltr">On Sun, Apr 4, 2021 at 2:41 AM Axel Sve= nsson <<a href=3D"mailto:[email protected]" target=3D"_blank">mail@a= xelsvensson.com</a>> wrote:<br></div><div class=3D"gmail_quote"><blockqu= ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px= solid rgb(204,204,204);padding-left:1ex">On Sun, Apr 4, 2021 at 4:08 AM Ia= n Hickson <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= h</a>> wrote:<br> > There's a bug I run into sometimes that I can't quite reliably= <br> > reproduce,<br> <br> Reproducing it is your first problem. Try adjusting your configuration<br> with:<br> <br> set border 3<br> set fwcolor "#a00000"<br> set bwcolor "#0000d0"<br> <br> The above will help you double-check what frames ratpoison considers<br> active/inactive/empty.<br></blockquote><div><br></div><div>I've added t= hose, I'll report back if it helps with figuring out what's going o= n.</div></div></div></blockquote><div><br></div><div>For what it's wort= h, I just experienced this again. I think the last thing that I'd done = in ratpoison=C2=A0other than change focus was resize a frame, though that w= as a while ago.</div><div><br></div><div>The window that has keyboard focus= is the one in the frame with the fwcolor=C2=A0border. When I press the key= for "prev" or "next", the frame that I most recently r= esized is the one that gets its window changed, though the "Current=C2= =A0Frame" message appears over the window that is focused, not the one= that got changed. Resizing other frames doesn't affect the behaviour, = it continues to be that same frame that gets the window changed. Using &quo= t;exchangeleft" et al doesn't affect this. Using "only" = followed by "undo" doesn't fix it. After using "only&quo= t; to cause there to be only one frame, "prev" and "next&quo= t; do affect that frame. After splitting the frame with "hsplit",= it's the frame on the right that flips through the windows, not the fr= ame on the left, regardless of which has the "fwcolor" border. (I= nterestingly, the list of windows flipped through does change based on whic= h one has the "fwcolor" border and focus.)</div></div><div><br></= div><div>If I start from the state that's broken, then split the focuse= d window ("hsplit" does seem to affect the frame one would expect= it to affect), then it gets into a weird state where if the frame that was= stealing prev/next earlier is focused, or if a frame near it is focused, t= hen it gets the "prev"/"next" action, but otherwise the= newly created frame flips through available windows.</div><div><br></div><= div>Using "remove" to remove all frames then resplitting everythi= ng seems to fix the problem.</div><div><br></div><div>I'll keep trying = to figure out how to trigger this. It's not like resizing always trigge= rs it.<br></div><div><br></div><div>Cheers,</div>-- <br><div dir=3D"ltr" cl= ass=3D"gmail_signature">Ian Hickson</div></div> --000000000000287da605bf7daedc--