Add an overview/zooming feature

[TheCodedProf]

I'm wondering if it's feasible to add a zooming feature into niri, I'd be happy to work on it if pointed in the correct direction.

I currently have the issue that windows and columns tend to get lost between workspaces and I think one the best ways to fix this is adding zoom functionality. Zooming out should show the workspace above and below, show additional columns left and right (if they exist), make the windows showing non-interactable, and you should be able to click on a column to focus it.

[YaLTeR]

I thought about this a bit, I do have some vague ideas but nothing concrete yet. I'd need to experiment myself to tell what design I like.

[TheCodedProf]

If you'd be up to it, I'd be happy to call or just chat about possible designs, and issues that may come up with them :)

[YaLTeR]

Something I thought about was zooming out "all the way" so that you see all your workspaces top to bottom, then however many windows fits left and right on each of them. Then you can click on the window that you need, or scroll the strip on every workspace left and right.

Which is basically what you're suggesting, but zooming out even more.

[gyreas]

like the detached observer mode in video games? that's so cursed, and I love it!

[iron-III-neffide]

I thought of this exact thing and found this here, has it been implemented yet?

[Sempyos]

I think this became niri's overview feature: https://niri-wm.github.io/niri/Overview.html

[TheCodedProf]

That would work well. Though I wonder if it's better to have zoom stages, like adding more workspaces above and below the more you zoom out. Though doing it this was may be more work, it may be easier to tell what's on a window/what a window is, unless the thought is just to show the app icon on the area the window takes up.

[tv42]

I would love this. I still lose windows with Niri, I simply lose track of where I put them. Not having a workspace indicator, and workspaces disappearing when they're empty so their numbering keeps shifting, is probably what's causing that for me -- with Sway, I'd always have notes on 1, web on 2, code on 3, mail on 8, music on 9, etc.

ChromeOS's overview mode has been nice to me. If you haven't used it, note how it has both zoomed-out windows to pick from, and shows miniature workspaces.

https://chromeunboxed.com/how-to-try-new-window-snapping-overview-feature-on-your-chromebook-beta-channel-120/

Of course, Niri's window layout would make that look quite different -- but it's definitely proving the concept animated zoom out.

[morenathan]

I have this same problem. Sometimes I'll end up with 5 or 6 terminals and not realize it.

As much as I hate alt-tab in this type of setup, something that would just bring-up a mini live view strip of windows at the bottom, top, etc for that screen, when used, would really push Niri forward in usability.

I'm thinking along the lines of the "large icons" switcher for KDE, but with live window preview.

EDIT: re-reading other's posts, maybe when such a hotkey is pressed, a strip is shown for each active screen.

[salman-farooq-sh]

Only ~3 strips when zoomed-out, vertically scrollable, is better with window mini-previews.

All workspaces visible zoomed-out, is better with icons.

Strips being individually scrollable horizontally is great in either case.

The problem with choosing between window previews and icons is neither one has solved the problem at least for me. Same icons can be present multiple times, e.g. in case of terminal windows but mini-previews can also make windows difficult to identify e.g. in case of terminal windows again. Assigning icons with window rules or something will be almost ideal. I know Brodie Robertson makes news videos on this wayland protocol.

Maybe choose between icons and mini-previews dynamically based on number of workspaces?

[YaLTeR]

GNOME Shell shows both previews and icons, seems to work well.

[salman-farooq-sh]

The position at which the gnome shows the icons on the previews by default looks better with a bit of empty space in-between the previews, at least at the bottom. I had in my mind even padding on each side of the previews for the overview in niri. Maybe have icons positioned in the center of the previews? Just throwing my personal preference vote into the discussion.

^Random image from google visualizing what I mean (replace the touch thing with mouse scrolling, though I think with properly thought out touch and touch gesture support niri will be an absolute futuristic looking beast!! I can totally see niri being full operable with only a touchscreen on tablets)

[artlessgarden]

Cool, it is minimap in game.

Hopefully, may add one-click to destination key bindings.

[boomskats]

My opinionated take on this, in case it helps. As a user who transitioned to niri after a decade+ with i3/sway, here's how I would intuitively expect this to work:

I wouldn't override any keybindings or mouse behaviour as users will have already configured and customised that to their liking. Instead, keep the same key bindings and use the same workspace navigation actions, just within a zoomed-out view.

In terms of additional actions to implement, I can see this working very well with just one: zoom-monitor-toggle. I can see myself using this very regularly to zoom out and either navigate or reorganise my workspaces using all of my other bindings for move-xxxxxx-xx-xxx while in that mode (which is the killer feature here imho). I don't think anything else would be required for a first release. I don't have an opinion on whether it should toggle the zoom mode on the active monitor or across all of them, although I expect it would be easier to implement across all monitors simultaneously with a single state.

Further down the line you might want commands for zoom-monitor-out, zoom-monitor-in and zoom-monitor-cancel, but the more I think about this the less I think they'd be needed. Just that toggle would be amazing.

[tv42]

Ideally, the zoom in/out should track a touchpad pinch gesture or multi-finger drag from bottom or such.

[ThatOneCalculator]

Imo, this looks beautiful!

[elkowar]

For the keybind stuff: I'd think one cool approach could be allowing doing something like double pressing mod before holding it, which could then just let you stick to all the same keybinds as usual, but in the zoomed out view, until you let go of the mod-key

[mastoca]

I agree this is the right approach. I'd advocate to tackle it iteratively beginning with just having view - select/jump action, as that wouldn't change state of all the windows and likely has a lot less edge cases to contend with.

[thepragandsensdiary]

How did @boomskats made the animation? I'm kinda jealous on how good it looks~

[vncnz]

The zoom-out idea is very good, I miss the KDE's "exposè" effect and this zoom-out idea in @boomskats animation is the best for a scrollable-tiling compositor.

Another way to resolve the lost-windows-problem is to have a sort of horizontal scrolling bar and below each window its appicon: center aligned for visible windows, piled up on the left/right for not visible windows. I was thinking about something like that done with EWW but I know that it's not possible for now to retrieve the list of open windows through niri msg.

[tv42]

Personally, icons are much less useful to me than thumbnail previews or titles. "A browser window", "a terminal window" or "an editor window" tells me practically nothing, but almost all of my windows are one of those.

[salman-farooq-sh]

I don't want a bar taking so much screen space when it's possible to do without. But it's a cool idea.

[ilyist]

I would like to have things modular since the point of WMs is to be extremely customizable, modular, and unbloated, so could this be a separate program or plugin?

[Reffler]

Yep, thanks for the tip! That is actually my set up at the moment, and I consider it to be perfectly usable and pretty good. But yeah, I would also really like to bind multiple actions to the super key, having a workflow similar to what gnome does, where pressing super displays a zoomed out overview of the workspaces as well as working as a launcher is pretty compelling to me, not to mention it would look pretty good and fit Niri. But it's a very specific thing, and I am much more interested in the actual overview/zooming feature rather than searching on it. Maybe Rofi will even work nicely on top of the overview once it gets implemented (with enough customization).

[boomskats]

I also really like the idea of adding search to the overview - it would be a neat builtin feature (could be waaay nicer than rofi), and could make Niri more approachable for users coming over from Gnome. But fwiw I would avoid trying to completely emulate the behaviour of Gnome's overview feature. Setting the lack of native launcher aside, and just thinking out loud for a second:

1. Excluding live windows from the rendered layout isn't something Niri currently handles anywhere else afaik, and it would need to do that on every keystroke to filter the search results. I don't actually know if this is a big deal or not, but even so, I'm 'pre-emptively worried' about the complexity this would add & whether it'd be worth it.
2. The performance implications of recalculating the full tree on each keystroke could be significant. I'm sure the visual tests app would help surface issues here (as would @YaLTeR's latest adventures in wayland unit testing), but I imagine the layout updates would still have to run as a transactions per keystroke, and also finding a way to debounce between keyboard input and in-progress layout update animations without blocking either / making either feel laggy sounds like more effort than it's worth (note that this particular worry might stem from previous experience of severe system lockups during Gnome overview filtering back when I was on ye olde NVIDIA drivers - again, just thinking out loud).

As an alternative approach, you could avoid layout recalculations by using the existing window opacity implementation to indicate search results in the overview. Maybe something like this:

It could start to filter on keyboard input, and again use the same keybinds for navigating between search result windows as the normal mode does, just skipping the filtered out targets. The only thing I'm not sure about here is whether it would be better to keep the native window focus navigation behaviour (as shown in the anim above), where navigation selects a workspace and auto selects its most recently active column/window, or whether it would be better for the overview navigation mode to only apply the 'center-focused-column' workspace layout upon target window selection or L/R navigation within a workspace. In an unfiltered overview this doesn't matter because just traversing across a workspace to get to the one above/below it would never change its last state. But consider a (likely common) situation where the only focusable window in a workspace is outside the viewport - I don't think I would want that window pulled into view just because I activated its workspace while trying to reach a different one.

Also, FWIW, I really like the idea - or at least the option - of a 'fixed zoom-out' overview which scales all windows down by a predictable, fixed amount on each monitor, over one that tries to show all available windows in the same overview and scales everything down dynamically (i.e. how Gnome does it). However, if the fixed-scale overview also becomes a way of showing complete window search results, it will need to be able to hint to the existence of matching windows which are not currently visible/rendered - probably by adding some kind of arrows or partial border-like indicators at the edge of the overview viewport which hint to the user that there are more candidates beyond the fold. I imagine adding this would be a nontrivial amount of work, which the auto-scaled overview obviously wouldn't require.

Lastly, since we're talking about borrowing things from Gnome overview, I'm really hopeful that the interactive window moving mod-drag functionality introduced recently (in 0.1.10?) isn't too difficult to make work across workspaces in overview mode. I really like the idea of applying as many of the normal-mode keybindings and behaviours to the overview as possible.

[YaLTeR]

I very much like the idea to somehow gray out windows instead of straight up filtering them out from the layout. Implementation complexity aside (there would definitely be a lot), it's just better when unnecessary movement is reduced to minimum.

I don't think I would want that window pulled into view just because I activated its workspace while trying to reach a different one.

Definitely no "committing" to changes during typing.

Also, FWIW, I really like the idea - or at least the option - of a 'fixed zoom-out' overview which scales all windows down by a predictable, fixed amount on each monitor, over one that tries to show all available windows in the same overview and scales everything down dynamically

I agree, with our fixed window structure it should make more sense.

I'm really hopeful that the interactive window moving mod-drag functionality introduced recently (in 0.1.10?) isn't too difficult to make work across workspaces in overview mode.

It actually already works across workspaces: you can drag a window with a mouse with one hand, and touchpad-swipe in the middle of two workspaces with the other hand, and see that it all works. :p

---

All this said, I never actually found myself wanting to use textual search to reach a window. My comfy overview workflow in GNOME is: throw mouse into top-left corner, maybe scrollwheel through some workspaces, then click the window I want. So this much I will make work.

For the text search, if we get to it, I'll need advice from people who actually use that. Though, I'm now thinking how much complexity there is in just text input (let alone the underlying functionality) and my desire to do anything involving it drops heavily lol

[boomskats]

All this said, I never actually found myself wanting to use textual search to reach a window

110% agree and personally feel the same way - there is a perfectly functional existing solution to this, and if someone did want to implement something that cycles through previews of the search results, the niri msg windows and niri msg action rpc interfaces already provide everything I'd need to implement a search interface that can cycle focus through a list of matching windows. Infact the only thing that would be needed to 100% emulate the behavior in that last animation is an ability to do something like niri msg action set-window-property "opacity 0.5" --id XX, or niri msg action set-window-property "border 2" --id XX, which arguably could make sense regardless of this discussion.

I actually do something tangentially similar already that relies on the the rpc and jq and it's been bulletproof so far. I've been meaning to put it in a repo for a while.

#!/bin/bash
# this script is meant to emulate run-or-raise functionality,
# specifically for yalter/niri which waylands all by itself.
# requires jq and niri 0.1.9+

rorhome=/home/nik/dev/ror
runcommand="kitty"
appname="kitty"

launch() {
  dunstify -t 500 "Starting $appname"
  $runcommand
}

search() {
  cd $rorhome || exit
  winid=$(jq -f $rorhome/ws.jq \
    --arg app_id "$appname" \
    < <(niri msg -j windows))

# launch fresh instance if no match
  if [ "$winid" == "null" ]; then
    launch
  else
  dunstify -t 500 "Found $appname, focusing"
    niri msg action focus-window --id $winid
  fi
}

search

Again though, I'm only really writing all this stuff down to follow the search discussion through to a conclusion & explore what's doable. Personally I don't need any of this and would be very happy with just a zoom-toggle action that keeps all other keybindings and behaviours the same as the non zoomed-out mode. If it's easy to add, I think it'd be great if the action could accept a scaling parameter, enabling different key bindings for zoom-toggle 0.5, zoom-toggle 0.2, etc for different levels of overview zoom. I think that would be a lot more usable and predictable than what Gnome offers rn.

[phisch]

@boomskats What did you use to create that mockup animation?

[erikdubois]

I was missing a feature to zoom out and see all the windows that were open and where they are.

would be cool if it was included one day.

for other ideas and code maybe look at wayfire
https://youtu.be/y5fd_jSDH_Q?list=PLlloYVGq5pS4EGfRM5WIoisWqDKrJmjCk&t=22

[ravish0007]

I'm waiting for this feature to land as soon as possible, I stitched a hack.

#!/usr/bin/python3 -u
from subprocess import Popen, PIPE
import sys
import json


def get_selection(input_list, prompt="") -> str:
    """Get selection from list"""
    lines = str(min(len(input_list), 8))
    with Popen(
        ["fuzzel", "--dmenu", "-l", lines, "-p", prompt],
        stdin=PIPE,
        stdout=PIPE,
        stderr=PIPE,
    ) as fuzzel:
        selection = fuzzel.communicate(input=bytes("\n".join(input_list), "utf-8"))[0]
        if fuzzel.returncode != 0:
            sys.exit(1)
        return selection.decode().strip()


def get_windows():
    niri_windows = Popen(["niri", "msg", "-j", "windows"], stdout=PIPE, text=True)
    windows = json.loads(niri_windows.stdout.read())
    windows.sort(key=lambda window: window["id"])
    return windows


def make_selection_list(windows):
    return list(
        map(
            lambda window: f"{window['id']}) {window['app_id']}: {window['title']}",
            windows,
        )
    )


def choose_selected_window(selection):
    id = selection.split(")")[0]
    Popen(["niri", "msg", "action", "focus-window", "--id", f"{id}"])


windows = get_windows()
selection_list = make_selection_list(windows)
selection = get_selection(selection_list, "Choose window > ")
choose_selected_window(selection)

[Reffler]

Can you show what that looks like? Interesting

[benoliver999]

Here you go! It's a list of windows in fuzzel. Very handy thank you for making it @ravish0007

[kassick]

I've cooked a similar (if maybe over-engineered ;) ) solution here

It has a few more bells and whistles, such as filtering by current application, current workspace, active workspaces and current output.

If also shows the windows' workspace and output.

[YaLTeR]

Call for testing for the overview: #1440

[iron-III-neffide]

Then i ment sth different, i ment zooming out even more so you can see EVERYTHING Sempy ***@***.***> schrieb am Di., 7. Apr. 2026, 20:13:

…

I think this became niri's overview feature: https://niri-wm.github.io/niri/Overview.html — Reply to this email directly, view it on GitHub <#352 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BU4NRFSHO7OHLKUAWKSTQVT4UVAOPAVCNFSM6AAAAACXPINVDCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBYGAYDMNA> . You are receiving this because you commented.Message ID: ***@***.***>

[Sempyos]

There is a configuration for the zoom level here: https://niri-wm.github.io/niri/Overview.html#configuration

Along with a PR for zoom controls for it somewhere

[Atan-D-RP4]

full compositor zoom #3246

[iron-III-neffide]

O damn, this is sick thx you Sempy ***@***.***> schrieb am Di., 7. Apr. 2026, 20:17:

…

There is a configuration for the zoom level here: https://niri-wm.github.io/niri/Overview.html#configuration Along with a PR for zoom controls for it somewhere — Reply to this email directly, view it on GitHub <#352 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BU4NRFSBJE2UADU5LY4EC3T4UVA4TAVCNFSM6AAAAACXPINVDCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBYGAYTCMY> . You are receiving this because you commented.Message ID: ***@***.***>