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

Tiling mode navigation is unintuitive in multihead setups. #326

Closed
XV-02 opened this issue Feb 26, 2024 · 4 comments
Closed

Tiling mode navigation is unintuitive in multihead setups. #326

XV-02 opened this issue Feb 26, 2024 · 4 comments

Comments

@XV-02
Copy link

XV-02 commented Feb 26, 2024

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 use super + [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 using super + [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, but super + [down] never will, as focus will always move to display B. The inverse is then true for display B, when super + [down] can change workspace, but super + [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.

@Drakulix
Copy link
Member

Drakulix commented Feb 27, 2024

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 Super + [arrow key]: pop-os/cosmic-epoch#46

cc @pop-os/ux, as I understand the confusion here, but I am pretty sure this is behaving as intended.

@XV-02
Copy link
Author

XV-02 commented Feb 29, 2024

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.

@Drakulix
Copy link
Member

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.

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".

@nani8ot
Copy link

nani8ot commented Sep 12, 2024

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.

screenshot-2024-09-12-01-33-30

For now I've aligned them at the top-edge, which makes the workspace tiling model awesome to interact with!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants