Refactor traverse script and improve edge cases

[bodograumann]

I had some edge cases where the traverse script did not work well, so I took some time and refactored it and added:

• warp pointer to focused window
• focused window is brought to the front
• hidden windows are ignored
• candidates where the cross direction span overlaps with the current window are considered "in band" (previously only the center of the candidate was used)

The machinery might be a slight overkill, but it seems much more readable to me now :-)

[m-col]

Hey, thanks for working on this! The code itself looks fantastic. I'll have a test around with it today.

Can the cursor warping be configurable? I suspect it might be enough to warp conditional upon qtile.config.cursor_warp, rather than adding an option to these commands.

Similarly for window raising. One way would be to use the commands like this:

Key(
    mods, key, lazy.function(traverse.up), lazy.window.bring_to_front()
)

Alternatively having a default (as you have implemented) might make sense as it might always be expected. Is it worth adding an option to prevent the raise (default raise=True perhaps)

[bodograumann]

Good point. We should probably follow the way qtile does it. So warp on qtile.config.cursor_warp and maybe bring to front when qtile.config.bring_front_click is set?

[m-col]

(apologies for delay)

So warp on qtile.config.cursor_warp

yes for this

bring to front when qtile.config.bring_front_click is set?

but not this - best keep things related to clicking as separate. I think there are two options: 1) define a parameter to the commands like this:

def up(qtile, raise: bool = True):
    ... # (pass 'raise' along into _focus_window to do the raising

then users can disable it by using lazy.function(traverse.up, raise=False). Or alternatively 2) don't do any raising with these traverse functions - raising can be enabled like in the snippet in my previous comment, by passing a lazy.window.bring_to_front() to the Key. Pro: completely decoupled. Con: no raising by default. I'll let you choose which you think is best :) if you think the latter is probs the best way to go, we can always document it in the module docstring