-
Notifications
You must be signed in to change notification settings - Fork 98
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
Tiling mode navigation is unintuitive in multihead setups. #326
Comments
I am pretty certain this is in line with the intended workspace design (for cases where the workspaces and displays are on the same axis): pop-os/cosmic-epoch#13 Hitting the edge of workspaces, will advance displays without changing the displays workspace, so naturally you can end up in a situation that is not reversible. See also the keyboard navigation issue for the various behaviours of cc @pop-os/ux, as I understand the confusion here, but I am pretty sure this is behaving as intended. |
Agreed, reviewing those designs, it is working as intended. I think the issue might be how we're defining "vertical" and "horizontal" display association. When the displays are arranged side-by-side with their top edges aligned, it is easy to define them as horizontally arranged, and they act as such. When one top edge is higher than the other, they seem to be treated as also being vertical though. My guess is that we're comparing the locations of the top-left pixel for each display in the display space. But, that misses nuance in a lot of display setups where two displays share an edge extensively, but do not have easy alignments when you compare their origins or centers as points. I'll reach out to UX on this a bit. |
Right, what we could do is test for overlaps in edges instead of requiring a perfect alignment on the top-edge. (E.g. a monitor poking out a bit would still share much of that right/left edge, while they wouldn't touch on the top/bottom.) However I am not convinced, that this would solve all these issues. This isn't a straight forward or easy thing to solve as I believe a lot of these edge-cases exist. We should spell out how exactly this algorithm to determine display alignment should work before blindly testing possibly equally flawed "solutions". |
This issue has been annoying me for a while now, and I didn't find this issue at first because it's closed. Is there a reason not to reopen it? I've two monitors with different resolutions and sizes (1440p 27", 1080p 24"). They are clearly side by side, but moving a window located at the bottom/top of a workspace down/up, moves it to the next/previous monitor. For now I've aligned them at the top-edge, which makes the workspace tiling model awesome to interact with! |
At current, we use
super + [arrow keys]
to navigate window focus.On a single-head setup, continuing to move focus up or down will switch between workspaces where appropriate. This is in keeping with out vertical workspace schema. So, if I have two workspaces, and I am focused on a window which borders the top of the screen on workspace 2, and use
super + [up]
focus will move to the closest aligned window on workspace 1 which borders the bottom of the screen. If I then usesuper + [down]
focus will then move back to the best aligned window on workspace 2 which borders the top of the screen. This is effectively a path-reversible interaction. Reversing my inputs effectively reverses the action.However. on multi-head arrangements, the ability to shift focus across workspaces can lead to behaviour which is not path-reversible. If I have two displays, A and B, arrange side by side with one display's (let us assume B) top edge higher than the other, using
super + [up]
from the lower display can shift focus across displays, not across workspaces.So, if I am on workspace 1 on display A, and use
super + [down]
focus will go to workspace 2 on display A. But usingsuper + [up]
from this new focus will move focus to display B and not back to workspace 1 on display A.Similarly, in an over-under configuration with A over B,
super + [up]
can move focus across workspaces on A, butsuper + [down]
never will, as focus will always move to display B. The inverse is then true for display B, whensuper + [down]
can change workspace, butsuper + [up]
never can.This seems prone to causing confusion and frustration, and also seems like it might cause users to trip-up on understanding what each discrete keyboard shortcut does and how best to use them.
The text was updated successfully, but these errors were encountered: