rustn00b

Something similar is available for Sway in `swayr` (with a lockin delay). The delay is nice to ignore focus updates resulting from navigation actions with no "semantic" meaning. For instance,...

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

Been mulling this over, and all I can come up with is a system that involves release key bindings, e.g.: - 1 binding for `focus-window-mru-previous`, say `Mod-Tab` - 1 binding...

Wrt the delays chosen for other similar solutions: - swayr: 750ms "focus lockin_delay" by default [swayr-configuration](https://sr.ht/~tsdh/swayr/#swayr-configuration) - mutter: seems to have had a 150ms at some point (not sure about...

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

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

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

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

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.

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