More intuitive switch of focus

[nor-0]

Hello,

I think switching focus is a bit confusing in some situations. When focus is switched in a direction, it can end up diagonally instead of the frame next to the previously focused one. The minimal example for this is with four frames, but it also applies in layouts with more than four of them.

Let´s say I press the keybindings for these actions:
vsplit, hsplit, focusright, hsplit.
This leaves me with a layout of four simple quarters:

+-----+-----+
|  1  |  2  |
+-----+-----+
|  3  |  4  |
+-----+-----+

Now, using focuslefton frame 2 brings me to frame 3 instead of one. Likewise, focusright on frame 3 brings me to frame 2 instead of frame 4.

As soon as I resize a width, switching works as expected and desired. The oddness however reappears whenever the vertical frame edges are realigned.

The same trouble happens when creating the layout with the keybindings for hsplit, vsplit, focusdown, vsplit. Now, focusing up from frame 3 brings me two frame 2 instead of 1, and same with the symmetrical opposite again (2 downwards is 3 instead of 4). Now resizing heights is what helps until the horizontal edges are realigned.

As said before, similar things occur with more complex layouts. I use those much less frequently of course, but intuitive navigation is even more important then. In these two minimal examples, reaching the frames 1 and 4 is also often more tedious then necessary.

I understand this is due to the way the frames were created and makes some sense in this regard. However, unless there is some reason to keep this behavior (which disappears by some resize options anyways), I´d suggest to change it to be more intuitive.

I imagine an approach for this could be to determine the frames center point and then looking for an adjacent frame in horizontal (vertical) direction from there when focusrightor focusleft (focusdownor focusup) is used.

(Everything said about focus[direction] also applies to exchange[direction].)

[project-repo]

Thanks for the suggestion! Yes, I agree that the current implementation
is not a very satisfying solution... The reason it is handled like this
is simply because it was easiest to implement. Fortunately however,
changing this should not require too much coding since the
determination of the tile to jump to is handled globally by a single
function for each direction.

I like your idea with considering the center of the frame and then
looking for the one adjacent to it which is at the height of the center,
since such a frame is always guaranteed to exist (unless we are at the
edge of the screen in which case there is nothing to jump to).
Of course, this would have to involve some kind of tie-breaking when
two adjacent frames share a border at the height of the center (which is
bound to occur often if you never resize the tiles). I'm currently
leaning towards simply taking the top/left one in this case (or some
similar scheme) but if anyone else has thoughts on this, we'd be glad to
hear!

Some notes:

• This would be a breaking change, so the version number would jump to 2.0.0.
• Also, due to limited developer capacity at the moment and
  the ongoing porting of cagebreak to the wlr_scene API it may be a
  while until we are able to implement this, so bear with us!

cheers
project-repo

[project-repo]

We pushed some code to development implementing this in ed5cca9. Sorry for not writing this much sooner.

To anyone who reads this: This feature will remain on the developmentbranch for some time, partially due to some unresolved xwayland andwlr_scene bugs and partially to allow breaking changes. So if anyone would like to see something changed, please feel free to let us know!

cheersproject-repo

[project-repo]

Hi nor-0,

this is now part of release 2.0.0.

I am closing this issue.

cheers
project-repo