Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Focus right / left not shifting between floated to non-floated windows across monitors #3661

Closed
SamSaffron opened this Issue Mar 27, 2019 · 10 comments

Comments

Projects
None yet
4 participants
@SamSaffron
Copy link

SamSaffron commented Mar 27, 2019

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

Monitor 1, Workspace 1 is visible, a single floating window exists on it.
Monitor 2, workspace 2 is visible, a single non floating window exists on it.

focus left from Monitor 2 takes us to the floating window.
focus right from Monitor 1 does not return us non floating window

Expected Behavior

focus right should return us to the non floating window.

Environment

Output of i3 --moreversion 2>&-:

i3 version: 4.16.1 (2019-01-27)

Happy to try on git if it is resolved there.

The behavior feels to me like someone did this on purpose so focus does not bleed between floating / non floating, but I am not sure the multi monitor aspect was considered.

@i3bot

This comment was marked as outdated.

Copy link

i3bot commented Mar 27, 2019

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

@i3bot i3bot added the 4.16 label Mar 27, 2019

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Mar 28, 2019

Directional focus not leaving the floating layer is intended behavior, @Airblader do we want to change that?

@SamSaffron

This comment has been minimized.

Copy link
Author

SamSaffron commented Mar 28, 2019

@Airblader

This comment has been minimized.

Copy link
Member

Airblader commented Mar 28, 2019

I think the reason here is that for the floating layer focus wraps around the monitor. With only a single floating window this isn't obvious since we just focus the same one again, but try it out with multiple floating windows in a workspace.

Obviously we don't want to break this behavior in general, so the question is whether we'd want to special case the situation of there being only a single floating window in the workspace.

I'm leaning towards no as it seems to be very little benefit for the cost of making focus behavior even more complex.

@SamSaffron

This comment has been minimized.

Copy link
Author

SamSaffron commented Mar 28, 2019

@SamSaffron

This comment has been minimized.

Copy link
Author

SamSaffron commented Mar 28, 2019

OH I get the problem with a naive disable of focus wrapping, if you have a window completely behind another window ... it is super hard to move to it.... will play around in my ruby wrapper to see if I can come up with a sane algorithm but I totally grant this is a tricky problem @Airblader

@orestisf1993

This comment has been minimized.

Copy link
Member

orestisf1993 commented Mar 28, 2019

In case you are unaware, a simple way to move the focus to the next workspace is to focus the parent ($mod+a) and then use the directional focus command.

@SamSaffron

This comment has been minimized.

Copy link
Author

SamSaffron commented Mar 28, 2019

Thanks @orestisf1993 I have been working on minimizing magic I need to remember $mod-a def helps:

https://gist.github.com/SamSaffron/9e2947d69a057c1b9bff1a8c8be37e20

I totally get this a very tricky problem to solve cleanly due to floated window possibly being behind other floated windows.

@Airblader

This comment has been minimized.

Copy link
Member

Airblader commented Mar 29, 2019

I'll try to summarize:

  1. This is only a minor annoyance in a specific scenario with a clear, existing solution.
  2. Fixing this would create a similar minor annoyance in another case of overlaying floating windows.
  3. Even then it could/should only be fixed in a multi monitor environment since otherwise the behavior even makes sense, which would make focus behavior less consistent for users.
  4. And all of this would come at the price of increasing the complexity of the focus implementation.

I think overall this strongly suggests thst we shouldn't change behavior here. The only acceptable solution would be with a config flag, but this seems pretty overkill for such a case. I'll thus close this issue for now. :-)

@Airblader Airblader closed this Mar 29, 2019

@SamSaffron

This comment has been minimized.

Copy link
Author

SamSaffron commented Mar 30, 2019

@Airblader I implemented my breakout per:

https://gist.github.com/SamSaffron/5f8a2275f4334a0ecd23927a3c82aa55#file-i3-plus-L99-L154

It does add minimal complexity but I do see it as radically complex.

Will live with it for a bit and see how I like it seems to be working fine for me for now including dealing with the overlap. I think the focus algorithm of sorting by window center and picking next in sequence is a pretty reasonable approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.