ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ratpoison gets confused about what is the active frame


From: Ian Hickson
Subject: Re: ratpoison gets confused about what is the active frame
Date: Thu, 8 Apr 2021 15:36:26 -0700

On Sun, Apr 4, 2021 at 1:11 PM Ian Hickson <ian@hixie.ch> wrote:
On Sun, Apr 4, 2021 at 2:41 AM Axel Svensson <mail@axelsvensson.com> wrote:
On Sun, Apr 4, 2021 at 4:08 AM Ian Hickson <ian@hixie.ch> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]