please implement a “focus next” function

[i3bot]

[Originally reported by tanguy+i3wm.org@…]
(Focusing clients is currently implemented in a directional way: focus left, focus up, etc. It would be practical to have a “focus next/previous” function, that would allow to switch between all windows, or optionally between visible windows, in a layout-independant way.

The interest of such a function would be to have a single binding to switching focus, which is sometimes (often?) faster to use, even if one has to type it several times, than having to choose the key to use depending on the physical layout of the windows on the screen.

Technically, that would mean browsing the leafs of the tree, which I think is a classical algorithm.

[i3bot]

[Original comment by tanguy+i3wm.org@…]

Sorry I was not able to tag this ticket accordingly, but it is a whishlist request rather than a defect!

[stapelberg]

See http://bugs.i3wm.org/query/ticket/840#comment:1 on why we don’t want to implement alt+tab like window cycling:

Cycling through windows in focus order (like alt-tab) is something we don’t want to implement:

1. The order in which alt+tab switches through windows is not easily predictable (due to our internal tree layout), thus either not doing what you want or making a separate visual element necessary (like a window list).
2. Having such a visual element as discussed in 1 would need hand-eye coordination: you press a key (hand), then look at the screen, figure out what you want, then press another key.
3. Direction focus is quicker. Instead of having one shortcut to go through all windows, you have 4.

Maybe slowpoke’s window switching script (ask him on IRC) is what you are looking for.
If it’s not, maybe you can build your idea with the IPC interface. It’s not going to be in core i3, though.

[i3bot]

[Original comment by tanguy+i3wm.org@…]

Okay, I may code something of my own, although I do not agree on these arguments:

1. The visual element may simply be the focus indication. The window manager awesome only provides next/previous focus switching, even if the windows can sometimes end placed in a non-obvious way, and I never heard any complaint about that.
2. The current way of switching focus requires hand-eye coordination too: you have to look to the screen to check how the window you want to focus is placed relatively to the currently focused one, then choose the focus direction accordingly. Both methods require such a coordination in fact.
3. Mostly correct but there is another way of interpreting that: next/previous focus is simple (only two key binding, only one used at a time) thus quicker to use. In fact that depends on the user's habits, I would say.

[stapelberg]

Replying to comment 3 by tanguy+i3wm.org@…:

1. The current way of switching focus requires hand-eye coordination too: you have to look to the screen to check how the window you want to focus is placed relatively to the currently focused one, then choose the focus direction accordingly. Both methods require such a coordination in fact.
   The difference is that in the current way of directional focus, it is much easier to quickly develop a habit of switching between some windows during a typical development session. E.g. when you work with two stacked containers right next to each other, you can open new windows in either stack and switching left/right will still get you to where you think it does, while the order in a potential alt+tab like switcher would change due to new windows.
2. Mostly correct but there is another way of interpreting that: next/previous focus is simple (only two key binding, only one used at a time) thus quicker to use. In fact that depends on the user's habits, I would say.
   True. But i3 does not aspire to support everybody’s habits in a perfect way.

[MrTango]

Would be a function like workspace back_and_forth but for containers possible?
Because it would be really useful, if you switch between two windows.

[Airblader]

@MrTango You can use the IPC.

https://github.com/acrisci/i3ipc-python/blob/master/examples/focus-last.py