feat: add code for infinite window loop Between Left & Right

[dev24hrs]

First of all, I really like this software. However, there's one aspect I'd like to optimize during daily use: Unable to infinitely loop between windows.
For example: a -> b -> c -> d; however, d cannot switch to a be directly, and a cannot switch to d.
On my machine, it successfully loops left and right.
Since I do not use a top-and-bottom split-screen layout, I have not added any related code.
So I submitted a PR; I would appreciate your feedback or if you could merge it.

[mogenson]

Neat idea. Let's make this optional behavior. Please add a config option to config.lua and default the value to false. Then add a short description of the config and behavior to the README.

[dev24hrs]

Neat idea. Let's make this optional behavior. Please add a config option to config.lua and default the value to false. Then add a short description of the config and behavior to the README.

Hi, I have pushed the code back with adding a config option. I think the pr doesn't perfectly implement smooth scrolling.
For example, PaperWM manages 4 apps: a -> b -> c -> d. When I use the shortcut cmd+ctrl+L to execute focus_right, everything works perfectly because they scrolled in from right to left as expected.
However, when d is the last window on the right side of the screen, if I continue executing focus_right to scroll to a, a is successfully focused, but it scrolled in from left to right. But focus_left & focus_up & focus_down work perfectly.
The order of a, b, c, and d is not a circle.
I also tried pre-position window A to the right of window D, and it scrolled in from the right side of the screen as expected, but there were gaps in the animation during scrolling.
Given my capabilities, I accept the first option.
I'm wondering if you have the free time or interest to implement this feature yourself. Or do you have any suggestions for the submitted pull request?

[mogenson]

I did a quick test with this PR. It looks like the focus window behavior you implemented is working correctly.

For your example of windows a -> b -> c -> d, if I have window d focused and perform the focus right action, window a is focused and all windows slide right to ensure that window a is on screen. If I have window a focused and perform the focus left action, window d is focused and all windows slide left to ensure that window d is on screen.

Are you saying that you wish to not just focus a window, but change the order of the tiled windows? For example, if window d is focused and you perform focus right, do you want to move window a to the right of d, so the new order is b -> c -> d -> a? And same for the other direction?

[dev24hrs]

I did a quick test with this PR. It looks like the focus window behavior you implemented is working correctly.

For your example of windows a -> b -> c -> d, if I have window d focused and perform the focus right action, window a is focused and all windows slide right to ensure that window a is on screen. If I have window a focused and perform the focus left action, window d is focused and all windows slide left to ensure that window d is on screen.

Are you saying that you wish to not just focus a window, but change the order of the tiled windows? For example, if window d is focused and you perform focus right, do you want to move window a to the right of d, so the new order is b -> c -> d -> a? And same for the other direction?

Yeah , that's what I wanted to say.

[mogenson]

@dev24hrs I added a new commit to this PR to move the wrap around column of windows to the adjacent spot. I believe this is the effect you wanted to achieve. Please give it a try.

I did not do this for wrap around window focusing within a column. The window movement seemed unnecessary since you can always see all windows in a column.

[dev24hrs]

@dev24hrs I added a new commit to this PR to move the wrap around column of windows to the adjacent spot. I believe this is the effect you wanted to achieve. Please give it a try.

I did not do this for wrap around window focusing within a column. The window movement seemed unnecessary since you can always see all windows in a column.

@mogenson Thank you for your code ; it is the behavior I expected. I'd like to know if you will implement this wrap window feature in a later version.

[mogenson]

@mogenson Thank you for your code ; it is the behavior I expected. I'd like to know if you will implement this wrap window feature in a later version.

Do you mind if I add to your PR? I've appended the previous commit to move windows when wrapping and I just added a new commit to include unit tests for Window.focusWindow() and wrapping.

[dev24hrs]

Of course u can , it would be my honor. This feature in the PR is just my immature idea; it would be perfect if it could be added to the project plan and accepted by users.

[ArhanChaudhary]

Ha! Funnily enough, I was working on my own implementation that I was about to PR. Looks like the open source world has got me covered, great work!

[ArhanChaudhary]

I want to mention that my config currently has these bindings because I have ctrl+j/k bound to switching spaces.

focus_prev = { { "ctrl" }, "h" },
focus_next = { { "ctrl" }, "l" },

It looks like the implementation for infinite_loop_window is only active for focusing left or right window, not for focusing the next or previous window, hence this feature doesn't work for me. Would you guys be willing to implement that? If not I could give it a shot as it looks relatively simple.

[mogenson]

Would you guys be willing to implement that? If not I could give it a shot as it looks relatively simple.

I see no reason why this couldn't be supported for the next / previous actions. @ArhanChaudhary could you try implementing it? I'd be happy to review and help.

[ArhanChaudhary]

I have opened #151 :)