Some comments before looking in-depth.

First of all, MRU Alt-Tab is certainly one of the things I missed when testing out a blanketopen-floating true workflow for a week. And you can't implement MRU well outside the compositor.

But the reasons I was so far reluctant to open an issue for this are:

• I'm used to it having a GUI switcher like in GNOME Shell. Especially in the case of MRU across workspaces, it helps when you can visually pick a window without everything moving around underneath you.
• It's unclear how to bind it with the current system because it is not a discrete action. You mention that it kind of assumes Mod currently; I'm not sure it's a good idea to have it bindable at all if it relies on that assumption to work properly. Besides, I'd expect it to be Alt-Tab rather than Mod. And pressing Shift-Tab instead of Tab should go backward, etc. Tbh I'd almost prefer to just hardcode it and not expose as an action for now, until we figure out a better way?

Also, GNOME Shell differentiates between Alt-Tab and Mod-Tab where one of them goes across windows of the same app, and the other one doesn't. Do we need this?

This timestamp is not updated immediately, but only after
a small delay (lock-in period) to ensure that the focus wasn't transferred to
another window in the meantime. This strategy avoids upsetting the MRU order
with focus events generated by intermediate windows when moving between two
non contiguous windows.

How does this work elsewhere like Mutter/GNOME Shell? Does it also have a lock-in delay? Does it need to be configurable in niri?

Something similar is available for Sway inswayr (with a lockin delay). The delay is nice to ignore focus updates resulting from navigation actions with no "semantic" meaning. For instance, if you have focus-follow-mouse active, the windows you move over while on your way to your intended target probably shouldn't cause your "mental" map of recent windows to diverge with the WM's version. Likewise, with scripts that perform multiple focus updates over IPC when these updates are just a means to designate the target of the following actions. For instance, I have one that resizes a bunch of columns at once by focus each one and then setting their width and then finally restores the focus to the window that originally had the focus when the script was called. As a user I don't need to be aware these focus events ever happened.

With respect to everything moving around on its own, I was kind of happy that this was happening on workspaces that had (too) many windows. Moving through them was a hassle, arguably I should just organize my windows better ;)

I know that I personally missed this feature from swayr and have been really savoring having it back!

I agree with your point regarding the presumption that the next/prev bindings use theMod key. A more generic approach would be to detect the (first?) modifier key for these MRU actions and end the MRU sequence when that modifier key is released. Of course for it to feel right for the user, the modifier would need to be the same for both actions (not an unreasonable assumption).

Hardcoding would mean appropriating the shortcut, which is also a problem if you have users that like things the way they are now! With the PR as it is there shouldn't be any user visible impact if they don't have bindings defined for thefocus-window-mru actions.

Wrt the Alt/Mod-Tab distinction, iirc it allows navigation in a given application's windows or in all the windows (I haven't used Gnome in a while). I haven't given any thought to how the former is accomplished. Presumably some kind of app-id filter would be needed.

Does it need to be configurable in niri?

I played around with several values and settled on 500 millis but since this felt very arbitrary I made it configurable. Granted this would be an obscure setting that the majority of users would ignore except the few who think the default is terrible.

Been mulling this over, and all I can come up with is a system that involves release key bindings, e.g.:

• 1 binding forfocus-window-mru-previous, sayMod-Tab
• 1 binding forfocus-window-mru-next, sayMod-Shift-Tab
• 1release binding onMod that cancels any active MRU traversal.

This would allow users to pick arbitrary modifier and key combos to trigger MRU traversal.

My other ideas (e.g. auto determine leader keys) look as if they lead to clunky designs. In swayr traversal can be configured to expire after given delay (in my experience this is not always very intuitive).

Any thoughts on whether it is worthwhile to start tinkering with a release binding mechanism to support this?

I played around with several values and settled on 500 millis but since this felt very arbitrary I made it configurable.

Could you check what other similar programs or systems in programs use for this? I guess Mutter doesn't have any because it's only relevant for focus-follows-mouse and directional keynav, which it doesn't have. But for tiling WMs it should be relevant.

Been mulling this over, and all I can come up with is a system that involves release key bindings

Even if you "just" implement release keybindings (I expect this to be quite involved and error-prone on its own), then you kinda just take up the whole Mod release keybinding for something that should honestly happen automatically. That doesn't sound very good. (Besides, Mod release should get bound to overview when that happens.)

Hardcoding would mean appropriating the shortcut, which is also a problem if you have users that like things the way they are now!

Well yeah but the alternatives so far seem very clunky, making me think that hardcoding is the better solution, at least for now. Not sure

Wrt the delays chosen for other similar solutions:

• swayr: 750ms "focus lockin_delay" by defaultswayr-configuration
• mutter: seems to have had a 150ms at some point (not sure about
  the exact value bcs there are references stretching from 50ms to
  200ms in various forums and mailing lists), but the delay was applied
  before focus was transferred to the target window (and this annoyed at
  least some users:https://gitlab.gnome.org/GNOME/mutter/-/issues/888). This
  delayed-focus system appears to still be present and can be toggled with the
  focus-change-on-pointer-rest gsetting inorg.gnome.mutter.

As for jumping into the release key binding adventure just for this MRU feature,
it does indeed look like a tail-wagging-the-dog kind of situation ;)

Hard to argue against the simplicity of the hard-coded approach, so would you be
in favor ofAlt-[Shift-]tab then? What would the mapping in
the winit case then be,Modifiers::ISO_LEVEL3_SHIFT-[Shift-]tab?

Alt-(Shift-)Tab should work, yeah. Actually, we can do it like this: if the user has anything bound to Alt-(Shift-)Tab, then it will call their bind, otherwise it will do the built-in Alt-Tab. We already do this for e.g. Mod+MouseLeft.

if the user has anything bound to Alt-(Shift-)Tab, then it will call their bind, otherwise it will do the built-in Alt-Tab.

With the last few commits, this should be the resulting behavior. I still have to adjust to the Alt vs Mod layout but otherwise I find it quite comfortable to use.

An alternative for the lock-in delay could be user interaction with the window, i.e. any keyboard key or pointer button (not movement or wheel) that is actually sent to the application and not suppressed by the compositor. Maybe a combination of the two, whichever comes first?

Also I really dislike havingmru in the name, it's non-obvious to the point of forcing people to look it up, a config should generally prioritize clarity over conciseness and the rest of niri is really good at that. I can't think of a good name, but evenfocus-window-recent-previous andfocus-window-recent-next would be better, it's slightly broken English but it at least gives you a general idea. (I think justfocus-window-previous/next isn't clear enough, and should be reserved forlogical direction actions).

any keyboard key or pointer button (not movement or wheel) that is actually sent to the application and not suppressed by the compositor

I'm not convinced though, I often flip back between code and doc windows - the code windows get interacted with plenty, but the doc windows mostly just gets stared at. For now, my impression is that the implemented behavior feels quite natural - but that's obviously as subjective as it gets!

I can't think of a good name

Same here! Although MRU/LRU is quite common in projects I've dabbled in, I do concede that it may not be as generally understood as one could hope for.

a config should ...

If I'm not mistaken, the "MRU" actions shouldnot be available in the config. However they should be visible using IPC - not sure that makes any difference wrt your argument though.

Anyway I don't have any strong beliefs here, so I'm perfectly happy to go along with whatever the consensus is.

Maybe a combination of the two, whichever comes first?

This would work I think and shouldn't be too hard to achieve (I'm guessing). I can give it a shot time allowing.

The latest commit implements the behavior suggested by@bb651 above.
It turns out that this change allows for a less aggressive lock-in timer while at the same time feeling responsive to user inputs. Thanks to@bb651 for the great suggestion!

I haven't changed the name of the actions, will wait for@YaLTeR to weigh in on that one.

Tested and works great for me! I don't see a big problem with the hard coded alt-tab since that is the default shortcut on pretty much every common (and not so common) OS or desktop environment.

Since niri already has afocus-window-previous action (which is what I was using before trying this PR) and since you can override the hard coded mapping, there seems to be enough flexibility to be generally useful.

My opinion is worth less than $0.02 but I think this should suit most people's needs fairly well.

Is there a reason why this PR is still marked as Draft? Something still missing?

It's working fine for me, however I can't really speak to the changes for touch/tablets. I'll "ready for review" it then.

Gonna give it some testing.

First thing I noticed: at compositor startup, when I have auto-started windows on different workspaces, MRU doesn't go through all of the windows until I focus them the first time. And similarly, if a window is never focused on spawn (e.g. a dialog for an unfocused window, or withopen-focused false), then it is not added to the MRU, although it should (at least to the end).

For mru-commit-ms config, probably put it into a new section (like the newclipboard), but need to think of a name. Or maybe just don't have it in the config at all for this PR?

It's also weird that as you're navigating the MRU, it will scroll around and mess up all your workspaces and monitors, and won't restore them back when you pick a window or cancel. This wouldn't be a problem if MRU used a dialog to select windows instead of jumping to them. But that's a chunk of work by itself so idk.

MRU doesn't go through all of the windows until I focus them the first time

Fair comment, I'll add in something to include windows without a focus timestamp in the MRU list. This shouldn't be any trouble.

Or maybe just don't have it in the config at all for this PR?

I guess so, I don't really see anyone tinkering with this setting much. A dedicated section for only this would feel a bit bloated. So I'll just set the default 750ms as a static value and comment out the config related parts.

it will scroll around and mess up all your workspaces and monitors

Yup, especially with tabbing! Improving this was actually up next on my todo-wishlist but I haven't gotten actually started anything.

I think it would be cool to use the MRU order when closing a window, currently (in 25.02, haven't tested this PR but I don't see changes related to it) it seems to have logic to switch back to the previous window if you open a window then close it without switching focus in between, but for other cases it focuses the window to the right. This could be an option, not sure what the default should be.

Yeah, the current logic more or less follows the behavior you'd find in tab bars (think Firefox tabs or some such). Full MRU would be annoying (think switching workspace, then immediately closing a window, you don't want it to switch back). Maybe limited MRU within a workspace. But idk, I feel that the current logic feels fairly good