Return to previously selected window when navigating to middle of split

kabeersvohra commented

2021-04-07 14:30:04 +00:00

(Migrated from github.com)

This happens to me quite often when I split my workspace like this:

AB
AC

Where A is the pane which takes the whole of the left hand size of the screen and B is on top of C. If I am in the B pane and I focus left, the focus will move to the A pane (which is correct), however when I focus back right, the focus moves to the C pane, then moving left and right will move between A and C panes. I would expect this behaviour to move to the last selected pane so B -> A -> B -> A... and C -> A -> C -> A...

I was wondering if you could address this in the next update :)

This happens to me quite often when I split my workspace like this: AB AC Where A is the pane which takes the whole of the left hand size of the screen and B is on top of C. If I am in the B pane and I focus left, the focus will move to the A pane (which is correct), however when I focus back right, the focus moves to the C pane, then moving left and right will move between A and C panes. I would expect this behaviour to move to the last selected pane so B -> A -> B -> A... and C -> A -> C -> A... I was wondering if you could address this in the next update :)

budRich commented

2021-04-08 17:56:51 +00:00

(Migrated from github.com)

Hello Kabeer!
Interesting issue. At the moment i3viswiz tries to focus whatever window would be in the direction the focus is going and on the center (or slightly above) the current window:

scenario 1:
AAABB
AAABB
AAABB
AAACC

scenario 2:
AAABB
AAACC
AAACC
AAACC

scenario 3:
AAABB
AAABB
AAACC
AAACC

if one would focus right from window A in the scenarios above the results would be:

B
C
B

But I understand what you request, and it sounds nice, I would like that myself, but it might be very difficult to implement, since this would mean keeping the last focused container in memory somehow.. It is very possible in a i3fyra context, but not otherwise. I will definitely keep this in mind, I am working on viswiz right now, and maybe there is a smart way to do it, hmm. It also depends on if B and C (from your example) are siblings in the same parent container (which then would be split vertically), but they could be separate nodes as well, it's things like this that makes it tricky to implement.

possible solution

there is this other tool called i3gopher that keeps track of the last focused window and lets you add a keybinding to focus that last window, and it is smart so it doesn't store temporary windows and stuff.

Hello Kabeer! Interesting issue. At the moment i3viswiz tries to focus whatever window would be in the direction the focus is going and on the center (or slightly above) the current window: ``` scenario 1: AAABB AAABB AAABB AAACC scenario 2: AAABB AAACC AAACC AAACC scenario 3: AAABB AAABB AAACC AAACC ``` if one would focus right from window A in the scenarios above the results would be: 1. B 2. C 3. B --- But I understand what you request, and it sounds nice, I would like that myself, but it might be very difficult to implement, since this would mean keeping the last focused container in memory somehow.. It is very possible in a i3fyra context, but not otherwise. I will definitely keep this in mind, I am working on viswiz right now, and maybe there is a smart way to do it, hmm. It also depends on if B and C (from your example) are siblings in the same parent container (which then would be split vertically), but they could be separate nodes as well, it's things like this that makes it tricky to implement. --- ### possible solution there is this other tool called [i3gopher](https://github.com/quite/i3gopher) that keeps track of the last focused window and lets you add a keybinding to focus that last window, and it is smart so it doesn't store temporary windows and stuff.

kabeersvohra commented

2021-04-09 08:43:35 +00:00

(Migrated from github.com)

Hey Bud!

Thank you for getting back to me :) Yes so in the 3 scenarios you have above, I would fully expect 1 to go to B and 2 to go to C as those are the panes which are directionally right of A. In scenario 3, it seems to be going to C rather than B so I see that when there isn't a clear pane to choose, it goes slightly below. I was thinking that in this scenario it would go back to whichever was previously selected but I understand that is not easy. I actually do not know how my containers are laid out, the reason I decided to use i3viswiz is that I thought this was really unintuitive!

I am thinking actually with your i3gopher recommendation, if there was any way we can handle the ambiguous scenario and then pass it to i3gopher? For example in scenario 3 above, where there is not a clear decision to be made, we could instead invoke i3gopher and it would select the previously selected window.

Hey Bud! Thank you for getting back to me :) Yes so in the 3 scenarios you have above, I would fully expect 1 to go to B and 2 to go to C as those are the panes which are directionally right of A. In scenario 3, it seems to be going to C rather than B so I see that when there isn't a clear pane to choose, it goes slightly below. I was thinking that in this scenario it would go back to whichever was previously selected but I understand that is not easy. I actually do not know how my containers are laid out, the reason I decided to use i3viswiz is that I thought this was really unintuitive! I am thinking actually with your i3gopher recommendation, if there was any way we can handle the ambiguous scenario and then pass it to i3gopher? For example in scenario 3 above, where there is not a clear decision to be made, we could instead invoke i3gopher and it would select the previously selected window.

👍 1

kabeersvohra commented

2021-04-09 08:45:54 +00:00

(Migrated from github.com)

And as soon as I wrote that comment I realised it wouldn't work:

AABBCC
AABBCC
AABBDD
AABBDD

Here if we went from A right and then right again, it would go A -> B ->A which would definitely not be expected. I understand that this is a complex problem so I appreciate you taking a look at it!

And as soon as I wrote that comment I realised it wouldn't work: AABBCC AABBCC AABBDD AABBDD Here if we went from A right and then right again, it would go A -> B ->A which would definitely not be expected. I understand that this is a complex problem so I appreciate you taking a look at it!

👍 1

budRich commented

2021-04-09 19:57:30 +00:00

(Migrated from github.com)

I am thinking out loud here a bit, i can't promise anything and it might be a bad idea, but:

AB
AC

We go to A from B (left), then store that info on container A. If we later go right from container A, we check if the proposed container (which probably would be C, assuming the lower container) matches the last focused container. It will not match, we then check to see if that container (B) is aligned on the same split as C, if it is we focus that, otherwise focus C. I think this is doable, and we only change this last focused container thing, whenever we focus left|right|up|down (not if a new window would automatically get focus ). And we only need to store one single thing something like: last_directional_focus=A-B, yes i think this can work fine, i can store it in a mark on the root node or something. I don't like the idea of writing this "variable" to a file, since focusing can sometimes be very frequent (if the delayed autoshift is triggered by holding a key, it would mean ~10 file operations/second..).

I am thinking out loud here a bit, i can't promise anything and it might be a bad idea, but: ``` AB AC ``` We go to A from B (left), then store that info on container A. If we later go right from container A, we check if the proposed container (which probably would be C, assuming the lower container) matches the last focused container. It will not match, we then check to see if that container (B) is aligned on the same split as C, if it is we focus that, otherwise focus C. I think this is doable, and we only change this last focused container thing, whenever we focus left|right|up|down (not if a new window would automatically get focus ). And we only need to store one single thing something like: `last_directional_focus=A-B`, yes i think this can work fine, i can store it in a mark on the root node or something. I don't like the idea of writing this "variable" to a file, since focusing can sometimes be very frequent (if the delayed autoshift is triggered by holding a key, it would mean ~10 file operations/second..).

kabeersvohra commented

2021-04-10 14:05:00 +00:00

(Migrated from github.com)

if that is possible I definitely think that would be nice :). Just trying to consider edge cases, if we have a situation like this:

DEF
AAB
AAC

Lets say we start at B and focus left, therefore storing last_directional_focus=B inside the node at A. We then focus up which moves to node E since B does not lie on that split (correct action) and then we focus left to focus D and then back down, hence last_directional_focus=D gets stored within A. We would lose the memory of previously selecting B (unless we store the last focus for each direction) but I think that is fine. I also agree that these should be stored in memory and not in a file. Also if we are using node id's, we should not have any issues with nodes being deleted and new ones being created either.

As a small side note, I also think that in the scenario of:

AB
AC

when focusing right from A and there is no last directional focus, I would expect B to be selected and not C, not a big deal but if its easy to add into this change it would be appreciated

if that is possible I definitely think that would be nice :). Just trying to consider edge cases, if we have a situation like this: ``` DEF AAB AAC ``` Lets say we start at B and focus left, therefore storing `last_directional_focus=B` inside the node at A. We then focus up which moves to node E since B does not lie on that split (correct action) and then we focus left to focus D and then back down, hence `last_directional_focus=D` gets stored within A. We would lose the memory of previously selecting B (unless we store the last focus for each direction) but I think that is fine. I also agree that these should be stored in memory and not in a file. Also if we are using node id's, we should not have any issues with nodes being deleted and new ones being created either. As a small side note, I also think that in the scenario of: ``` AB AC ``` when focusing right from A and there is no last directional focus, I would expect B to be selected and not C, not a big deal but if its easy to add into this change it would be appreciated

👍 1

budRich commented

2021-04-10 21:08:27 +00:00

(Migrated from github.com)

when focusing right from A and there is no last directional focus, I would expect B to be selected and not C, not a big deal but if its easy to add into this change it would be appreciated

It is very easy to add, and I will do that. I have also noticed that i am cheating a bit, regarding to the position of the bar, this is related, and also something that will be more accurate (it is important for multimonitor support to work).

We would lose the memory of previously selecting B

Yes, I think the best implementation will be to only store one single last direction, last_directional_focus=A-B where A and B are Container ID's and that example would mean that the last directional movement was from A to B, it doesn't matter which direction (left, right, up, down). This means that it will be replaced whenever we focus in a direction:

DEF
AAB
AAC

Lets say we start at B and focus left
last_directional_focus=B-A

We then focus up which moves to node E
last_directional_focus=A-E

then we focus left to focus D
last_directional_focus=E-D

then focus down to A
last_directional_focus=D-A

then focus right
well since the B container is at the center of the vertical split, it will actually in this case focus B.

So, the memory will only work when one focus back in the opposite direction, but I believe this will be good enough. The reason why this is better is that we only need one single place (mark) to store the info. Storing this for each window (and direction), would be really messy if it's done with the current method.

focus in the future

I am quite tempted to experiment with a version of viswiz implemented in Go similar to how i3gopher works, doing so would make things like this a lot easier.

> when focusing right from A and there is no last directional focus, I would expect B to be selected and not C, not a big deal but if its easy to add into this change it would be appreciated It is very easy to add, and I will do that. I have also noticed that i am cheating a bit, regarding to the position of the bar, this is related, and also something that will be more accurate (it is important for multimonitor support to work). > We would lose the memory of previously selecting B Yes, I think the best implementation will be to only store one single last direction, `last_directional_focus=A-B` where A and B are Container ID's and that example would mean that the last directional movement was from A to B, it doesn't matter which direction (left, right, up, down). This means that it will be replaced whenever we focus in a direction: ``` DEF AAB AAC ``` >Lets say we start at B and focus left `last_directional_focus=B-A` >We then focus up which moves to node E `last_directional_focus=A-E` >then we focus left to focus D `last_directional_focus=E-D` >then focus down to A `last_directional_focus=D-A` >then focus right well since the B container is at the center of the vertical split, it will actually in this case focus B. So, the memory will only work when one focus back in the opposite direction, but I believe this will be good enough. The reason why this is better is that we only need one single place (mark) to store the info. Storing this for each window (and direction), would be really messy if it's done with the current method. ## focus in the future I am quite tempted to experiment with a version of viswiz implemented in Go similar to how i3gopher works, doing so would make things like this a lot easier.

budRich commented

2021-05-29 15:09:46 +00:00

(Migrated from github.com)

this feature is now implemented in i3viswiz

Rows
Columns

Return to previously selected window when navigating to middle of split #84

possible solution

focus in the future