Window MRU, now with a UI

[rustn00b]

This PR is an updated take on #977 which it supersedes. It
provides a UI to navigate currently open windows sorted in most-recently-used
order (MRU). At present it is not yet ready for prime time, most notably
because features like animations are missing. However (imho) it has proven to
be quite usable!

Because it includes a separate UI to navigate thumbnails of the open windows, it
should not suffer from the same shortcoming as #977 where the latter would mess
up the current disposition of tabs and workspaces because it relied on actual
focus changes to perform the MRU traversal.

Here's the list of what is supported:

• activate the MRU UI using either Alt-Tab or Alt-Grave, the former traverses
  among all open windows ("None" filter), while the latter only traverses
  windows that share the same app-id as the currently focused window ("AppId"
  filter).

  Each window is represented by a thumbnail version of the original.

  Adding Shift to the key binding makes the traversal happen in the opposite
  order.

• when the UI is opened:

  • regular key bindings are filtered.

  • using Alt-Tab or Alt-Grave allow switching.
    traversal modes on the fly. Toggling the AppId filter uses the app-id
    of the current MRU selection (as opposed to the window that had the focus
    when the UI was opened).

  • releasing the Alt key transfers the focus to whatever thumbnail was
    selected in the MRU UI.

    Note: This implies that using key bindings that don't use the Alt modifier
    won't behave quite as expected because the UI will not close when they
    are released. So for now at least it's Alt-* only.

  • Esc closes the MRU UI and returns focus to the
    window that originally held it when the UI was invoked.

  • q closes the window/application for the currently selected
    thumbnail.

  • a, o or w change the "scope" of the windows shown in the MRU UI:

    • a: consider all open windows
    • o: consider only windows on the current Output
    • w: consider only windows in the current Workspace

  • s Cycle through "scopes" (All/Workspace/Output)

  • j/k and Left/Right can also be used to navigate thumbnails.

  • Home/End jump to the first (respectively last) thumbnail.

Key bindings are all hard coded (except for a configurable common modifier key).
Those that open the MRU UI (Alt-Tab, Alt-Grave and their Shift-ed variants) use a lower binding priority so
they shouldn't interfere with bindings already set in the configuration file. The flip-side
is that no error is reported if an existing binding masks one of those of the MRU UI.

As of 414284c, the UI can be configured in the recent-windows section of the Niri configuration file:

• The modifier key can be set to something other than "Alt" (the default), e.g. "Super"
• The UI can be disabled with the off child node.

recent-windows {
    // Uncomment to disable the recent windows interface
    // off

    // Choose the modifier key for the recent windows interface
    mod-key "super"

    // use thumbnail selection animation (expands selected thumbnail to selected window's position)
    // enable-selection-animation
}

Most glaring remaining todos:

• Animations
• Support for pointer actions, eg. clicking on thumbnail should close
  the UI and focus the corresponding window.
• Allow the UI key bindings to be disabled
• Configurable modifier key for the hard-coded keybinds, e.g. <MOD> + Tab
• Add a threshold duration for open-to-close of the MRU UI. If the threshold isn't reached, skip displaying
  the thumbnail selection animation.
• Add navigation bindings for H and L
• Fix scope changes causing motion of the selected thumbnail when there are enough other tiles to fill the display to either side.
• Don't transfer the UI to a different monitor if the mouse is moved there.
• Rework how the window border is rendered for thumbnails.
• Rework shortcuts and mechanism to cycle through scope filters (All/Workspace/Output)
• Adjust thumbnail size for the display where the MRU UI gets displayed instead of simply using 1/2 size.
• Moving the mouse over thumbnails should update the focus ring.
• Display all window titles instead of only the one for the focused thumbnail.
• Close the UI on mouse click outside of a thumbnail.
• Add explicit clipping to thumbnails

Despite all that, hope you all enjoy!

[jbms]

It would be great for all the key bindings to be fully customizable.

Also it would be great if this could be fully controlled by ipc (e.g. list of window IDs to include in preview), so that you could have layer shell application that handles its own key bindings and then modifies the preview.

[rustn00b]

It would be great for all the key bindings to be fully customizable.

The tricky bit here is that the UI needs to be dismissed with the mod key (Alt for now) is released. Hard-coding the bindings side-steps that problem by just wiring the behavior directly in Niri. Something more flexible would involve figuring out what mod (mods?) were used to open the UI to then detect when they are released. Doable, but might be clunky, especially if there is a more general way to deal with key release bindings in the wings.

Wrt bindings used within the UI itself, either the config would need to support some form of "mode" or maybe a separate binding section would be needed for this UI. Idk.

Also it would be great if this could be fully controlled by ipc.

This shouldn't be too difficult, basically the UI first builds a list of window IDs when it first opens. To fit into what you describe, the only difference would be to allow that list to be fed from IPC.

Although these ideas are definitely interesting, I think there's more work to be done on just the base functionality before tackling more new stuff (at least on my side)!

[YaLTeR]

Before looking into the code, would it be feasible to have 1 commit with the previous MRU PR (that I reviewed) and then 1 commit with all the new stuff? So it's easier for me to review just the new changes.

basically the UI first builds a list of window IDs when it first opens

Does it work with windows opening/closing dynamically?

[rustn00b]

Does it work with windows opening/closing dynamically?

Yes, at least that is the intent. You can actually use the Alt-q from within the UI to close windows as you navigate.

would it be feasible to have 1 commit with the previous MRU PR (that I reviewed) and then 1 commit with all the new stuff.

Aside from the focus timestamp tracking, most of the MRU code has changed. I can try to create a branch from current main, apply/squash the old PR onto there and do that again with the new PR. From there do you mean that I should close the current PR and open a new one containing just those two commits?

[rustn00b]

I set up a new branch with just the two commits on top of 8ba57fc, the first matches the most recent state of #977, and the second has the rolled up changes for this PR. It is available here.

@YaLTeR, should I just close this PR and reopen another based on the "squashed" branch? Tell me whatever makes things simplest for you.

[YaLTeR]

Oh, if most of the code changed, then I guess that's not necessary. Thanks for the branch, I can use it as a reference, so just keep it up for now.

I see that you bumped MSRV from 1.80 to 1.83 and applied some clippy lints (is_none_or). Is that strictly necessary? I don't have a concrete MSRV policy for niri but if it's just something minor like is_none_or then I'd prefer keeping 1.80 MSRV for now. Regardless, those changes should be in a separate PR.

There's also one formatting change to window_matches() that I noticed, why did that happen?

[rustn00b]

I see that you bumped MSRV from 1.80 to 1.83 and applied some clippy lints (is_none_or). Is that strictly necessary?

It was needed to support ControlFlow::Break / ControlFlow::Continue, which made things look clearer than the version I came up with before.

Regardless, those changes should be in a separate PR.

So, I'll wait on your opinion regarding the appropriateness of using ControlFlow in this PR, and assuming you are in agreement, then I'll break out the MSRV part and do a separate PR.

There's also one formatting change to window_matches() that I noticed, why did that happen?

That was cargo-fmt, definitely nothing manual.

[rustn00b]

Regardless, those changes should be in a separate PR.

Available in PR #1717

[rustn00b]

ac4c5d3 adds some animations giving the whole thing a more polished feel. Ideally transitions out of the UI should make it more obvious how the focus transfers to the focused window. I'm leaning toward a resize + move animation to make things nice and obvious.

[rustn00b]

This last update adds a thumbnail selection animation that improves the UX as it gives a visual indication of where the window for the selected thumbnail will appear. For now, the selected thumbnail doesn't properly handle cases where the window is resized while the thumbnail is expanding (the animation skips directly to the requested aspect ratio instead of scaling smoothly) and it also doesn't display the focus ring. Implementing these would involve duplicating stuff already better done in tile.rs. Unfortunately I haven't managed to grok how to use the OffscreenBuffer properly, which seems like the way to do it right.

[madeleine313]

Hello.

May I ask whether an option to disable this feature would be available? My concern being that I cannot use Alt and Tab at the same time as it interferes with some software/clients I use, and being able to disable this feature would be a work-around for not being able to customise the modifier(s)/keybindings if the bindings end up being hardcoded.

I would personally like to be able to use Super + Tab (which also brings up the "alt-tab menu" in GNOME and if I remember correctly Plasma as well) instead of Alt + Tab.

Thank you for your work and time!

[rustn00b]

Hi there!

May I ask whether an option to disable this feature would be available?

Not a bad idea, one could easily imagine a user either not wanting interfering keybinds or just wanting to use some different external tool to navigate recently used windows. I'll push this onto the todo list.

I would personally like to be able to use Super + Tab

Amusingly the PR from which this one is derived did use Super + Tab, but the consensus on the comment thread at the time was that Alt + Tab was preferable! Anyway, this seems like a pretty good indication that a little time should be spent on making this at least somewhat configurable. One possible step in that direction would be to allow configuration of the modifier that opens the UI, e.g. <MOD> + Tab. Also added to the todos.

[graham00]

All this looks great!

Also it would be great if this could be fully controlled by ipc.

This shouldn't be too difficult, basically the UI first builds a list of window IDs when it first opens. To fit into what you describe, the only difference would be to allow that list to be fed from IPC.

Just to add to that - I heavily use a type-to-seek ipc<->fuzzel script to jump to specifically titled applications and/or named workspaces:

#!/usr/bin/env bash
windows_list=$(niri msg -j windows | jq -r '.[] | "\(.id)\t\(.title) (\(.app_id))"')
workspaces_list=$(niri msg -j workspaces | jq -r '.[] | select(.name != null) | "WS: \(.name)"')
selected_line=$(printf "%s\n%s" "$windows_list" "$workspaces_list" | fuzzel --dmenu --width=200 --lines=55)
if [ -n "$selected_line" ]; then
    if [[ "$selected_line" == "WS: "* ]]; then
        workspace_name=$(echo "$selected_line" | sed 's/^WS: //')
        niri msg action focus-workspace "$workspace_name"
    else
        window_id=$(echo "$selected_line" | cut -f1)
        niri msg action focus-window --id "$window_id"
    fi
fi

Having MRU data available via IPC would be a godsend.

[rustn00b]

Having MRU data available via IPC would be a godsend.

30c5cf3 includes focus timestamp data in the the JSON output of niri msg windows (and in the event-stream). Timestamps are serialized using two fields, e.g.:

    "focus_timestamp": {
      "secs_since_epoch": 1755189524,
      "nanos_since_epoch": 71588761
    }

If for whatever reason a window never received focus, the focus_timestamp should be null (I haven't tested this), though Serde also offers the option to just skip the field in that case which may be a better solution. idk.

This isn't quite "full control over IPC", but it should still provide enough data to implement external MRU navigation.

[elcste]

This is amazing!!! I tried sway a few years ago but missed a good MRU switcher and went back to Gnome. Alt+grave for same app is the icing on the cake and q to close is the cherry on top :-)

I know this is not complete, but my feedback is that the animation is a little much for me when quickly switching back and forth between two windows. It looks good when pressing tab multiple times to select a window. I think Gnome Shell has a timeout and doesn't show an animation for their switcher if it is invoked very quickly.

Thanks again!

[rustn00b]

@elcste, that makes sense. Adding a threshold time to trigger animations shouldn't be too hard to do so I'll just add that to the Todos. Thanks for the comment!

[rustn00b]

0a7df42 inhibits the thumbnail selection animation unless the MRU UI was open for longer than a threshold duration. The threshold is hard-coded to 250ms, if that settings turns out not to be comfortable for everyone then it could be migrated to the "recent-windows" configuration section. Until such a time, I'm partial to keeping config clutter under control.

[elcste]

That's a great improvement. I might play with the timeout and try slightly longer. I'll report back if I really prefer it.

One other thing I've noticed: If I press Alt+Tab with only one window open – or Alt+Grave with only one window open of the same app – focus doesn't return correctly to the window. Clicking in the window doesn't help. I have have to do something outside that window, like switch workspaces, open fuzzel or invoke this switcher (like I can Alt+Tab if I got stuck on Alt+Grave). The apps I tried with were Alacritty, Ptyxis, Firefox and Sublime Text in case it matters.

[rustn00b]

If I press Alt+Tab with only one window open – or Alt+Grave with only one window open of the same app – focus doesn't return correctly to the window

@elcste, I haven't run into this personally although I do use alacritty as my "test subject". My usual (manual...) tests include the cases you describe (calling the UI with 0, 1, several windows). It's also intriguing that even clicking in the window doesn't trigger a focus update. The only similar situation I've encountered is with niri-in-niri and switching windows in the "outer-niri" while a modifier key was active in the "inner-niri".

Is this something you've encountered with just the latest version from yesterday or is this something you've noticed in older versions?

[elcste]

I think I noticed it before you added the animation threshold. I can't remember now if you had added the IPC commit or not.

A little more I noticed. It seems like it could relate to the Alt key still being active somehow? I'm seeing things that also happen if I hold the Alt key.

• After using the switcher with one Ptyxis window, when I type I get the app error "visual bell" of invalid input.
• In an app with a menu, the mnemonic letters are underlined.
  • In Sublime Text, the main menu bar. And focus seems to be stuck on the menubar, which I can flick
  • In Ptyxis and Gnome Disks if I press Alt+Grave with the app menus open, I see the mnemonic letters in those menus.

I use some xkb options that move around some modifier keys like Alt, but I get the same result with the stock config file.

[rustn00b]

@elcste: Ah, thanks for those indications. With your description I was able to hit it too, and now I'm wondering how I could have missed noticing it up until then! The tldr is that while the Mod (e.g. Alt) key press event was sent to the focused app, the corresponding release event was getting intercepted. So 63de4d0 now forwards the release event and this should hopefully address the issue you were seeing.

[elcste]

@rustn00b That must have been it – I'm not seeing it after your latest updates :-)

[Sempyos]

I've been playing with this for a while and have had no issues from my fiddling, great works !

[YaLTeR]

Haven't looked at the code yet, some feedback from 2 minutes of playing:

1. Wow this is really cool! With anims and all even

2. Wait you even got the window titles working, nice

3. It should be H and L, not J and K

4. Not sure about the Q. It's right next to Tab, and there's no confirmation, making it very easy to close a window by accident.

5. The window shouldn't animate from within the Alt-Tab to its position on the workspace. Just fade out or close the menu, no extra anim necessary.

6. The anim when switching between A-O-W modes is a bit jank, the windows move horizontally out of nowhere and other windows jump in.

7. Pressing Alt-Tab shouldn't close the Overview, it should just draw over it.

8. It should be sized relatively to the monitor logical height (like the Overview). Right now, switching from 2560x1440 to 1280x720, or equivalently changing scale from 1 to 2, results in a 2x taller Alt-Tab, when it should result in the same size Alt-Tab.

9. Windows don't redraw in Alt-Tab as can be seen with weston-simple-egl, they should.

   • Pay attention to windows that change size like wleird-resize-loop. This should work fine.

10. Mouse should be able to at least click to select the target window (and touch and tablet too).

    Right now, mouse seems to go "below" the Alt-Tab. I was actually planning to look into refactoring our Keyboard/PointerTarget to better support modal dialogs, I believe that would be useful for Alt-Tab too to solve this kind of issue.

11. Moving mouse to another monitor switches the Alt-Tab to that monitor. This is fairly abrupt; I think it should stay where it was. Also, all monitors should probably be dimmed, not just the monitor with the Alt-Tab.

12. Not sure how you draw the border in Alt-Tab, but it should definitely be thicker, and also it breaks on rounded corners:

    

    I've also seen the bottom border to be missing, which leads me to believe that you draw the border on the original Tile then downscale it, kinda like the Overview. Instead, perhaps try drawing the border on the already-downscaled Tile so that the border itself is not scaled?

13. Design-wise will need to play around and think more about it, remember what GNOME Shell does and what others do. Not prepared to give any feedback rn.

[yuukibarns]

I seem to find something not quite intuitive: when we switch from window A to an empty workspace below, then mru ui will still put the window A at the first, which means we will switch to window B after the window A in the list instead of more intuitive one, i.e., window A itself. However focus-window-previous does switch back to window A and then cycle between it and window B.

[YaLTeR]

I seem to find something not quite intuitive: when we switch from window A to an empty workspace below, then mru ui will still put the window A at the first, which means we will switch to window B after the window A in the list instead of more intuitive one, i.e., window A itself. However focus-window-previous does switch back to window A and then cycle between it and window B.

I did notice this today actually when reimplementing focus-window-previous. I cross-checked with GNOME, and their Alt-Tab also puts the window second, like niri currently does. I agree this feels less intuitive. I wonder what others do here like KDE or labwc?

[stefonarch]

Labwc doesn't change order if the switcher is opened on an empty workspace, kwin does a strange thing when not filtering per workspace: 3 windows, switching between 1 and 2 as most recent, when opening the switcher on the empty workspace 3 is selected...

[YaLTeR]

I additionally checked Windows. There, if you minimize all windows, Alt-Tab keeps the first window selected (doesn't switch next). But Alt-Shift-Tab also keeps the first window selected.

I think it's the most intuitive if in this case Alt-Tab keeps the first window, while Alt-Shift-Tab still selects the very last window. So that's what I just pushed in niri.

Also made scroll wheel binds work in the MRU (they are also in the "automatically picked up from normal binds" category, so make sure they're bound).

[YaLTeR]

Some more cleanups and fixes, incl. made tablet input work in the MRU and regular mouse binds get autoconverted too.

[YaLTeR]

Alright, everything's squashed now, should be good to merge. Unless some last minute issues come up.

[Vortriz]

Tested with default config. Working without any hitches 👍

[yuukibarns]

I have a somewhat nuance feature request for the case when there is no window focused. Currently, the selected window will popup abruptly without any sliding animation but in the normal case there is a sliding animation from the right to the center.

[YaLTeR]

Hmm? Not sure I understand

[yuukibarns]

Sorry for my bad English but I mean that when there is a focused window (the normal case), the switcher will arise as the second window slides in from the right to the center as if the switcher just appears in the middle of the sliding animation. But in the case when there is no focused window, the current behaviour is popping up directly without any animation. I hope there can also be some "slide from right to center" animation for the "no focused window" case.

[YaLTeR]

In the last commits I made it so that opening Alt-Tab from unfocused picks the first window rather than the second. That's why you don't see an animation. In general it's still there if you try Alt-Shift-Tab for example.

[yuukibarns]

Yes, I see but I mean that I wonder if we can add some slide animation even for the first window. I know this is not for everyone (that's why I call it "somewhat nuance"), but I think the current popup behavior of the first window is a little abrupt.

[YaLTeR]

Eh, idk. On other systems it also appears without animation. In niri (and GNOME) specifically there's already a 150 ms delay, so any further animation is adding even more delay until things "settle", I'd rather not probably.

[YaLTeR]

Alright let's continue on main. Thanks again @rustn00b for all of the work, and everyone for intermediate testing!

[rustn00b]

Thanks to all of those who chimed in here and made this happen!