Skip to content

feat: next/prev follows spatial layout, instead of MRU window list#471

Open
jessedhillon wants to merge 1 commit intodomferr:mainfrom
jessedhillon:feat-spatial-next-prev
Open

feat: next/prev follows spatial layout, instead of MRU window list#471
jessedhillon wants to merge 1 commit intodomferr:mainfrom
jessedhillon:feat-spatial-next-prev

Conversation

@jessedhillon
Copy link

This feature updates the feature introduced in #195: instead of next/previous window being determined by the window list, which is ordered by most recent use, we now apply a spatial ordering. The next window is the window which has the nearest equal or right X coordinate, with ties broken by comparing which one is closer to the top of the screen. In other words, we seek the window which is below us, then the window which is right of us, within the current desktop. At the edge of the desktop, we flip to the next desktop (determined similarly) and start the order again.

There's a picture included in the README which explains this. If desired, I can record a video to show the updated behavior as well.

@domferr
Copy link
Owner

domferr commented Jan 18, 2026

Hi! Thanks for the pull request. The idea is to have different keybindings: one that follows the spatial ordering (focus window to the left, to the right, above or below) and one that follows the MRU instead. Both are already implemented.

image

@jessedhillon
Copy link
Author

Hi @domferr if you recall, I implemented the MRU feature. This replaces MRU with a more predictable next/previous that is spatially aware

@domferr
Copy link
Owner

domferr commented Jan 31, 2026

Hi @jessedhillon sorry for the late reply. Yeah I recall, very cool feature! I appreciate your contributions to Tiling Shell 🥳

What I didn't understand is that there are spatial keybindings already (focus window to the left, right, above and below). Changing the MRU to spatial is going to implement the same no? And we will remove any MRU-like focus. What am I missing?

@jessedhillon
Copy link
Author

Hi @domferr, yes you're right. It was confusing for me to call this "spatially-aware" also. I'll explain it differently:

  • problem: MRU-based navigation is not intuitive. I think you'll find, if you ask people who use this navigation mode, that MRU is difficult to predict. On a single monitor, this problem is not very apparent because you might only have 2-3 windows, so it's not an issue if your navigation puts you one tile off from your intended tile. However, once you have multiple monitors you may have 7+ windows open, and the MRU window might jump to another monitor, and then the next hop after that might be again be on the wrong monitor. The window you want might be right next to the current window, but you might have to tap several times to get there.
  • solution: what's desired is that "next" and "previous" mean exactly "one predictable spatial neighbor".
  • why isn't ordinary spatial navigation good enough? Ordinary spatial mode provides two degrees of freedom: up/down, and left/right. But the motivation behind using next/previous is to restrict window navigation to one degree of freedom. Because some users (me, for example) use up/down to change virtual desktops, we don't want to range freely across all windows on the desktop, but to swipe through a spatially-aware ordering using left/right.

The MRU ordering was written before I knew very much about GNOME's windowing system, otherwise I would have written this to begin 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

Successfully merging this pull request may close these issues.

2 participants