IPC to return a list of open windows in the workspace

[jakesarjeant]

I love scrollable tiling, but when I have many windows open in a workspace, it can be hard to keep track of which one is where, and I occasionally find myself aimlessly SUPER+H/SUPER+Ling around my workspace looking for the right window.

I think it would be tremendously helpful if my bar could display an ordered list of open windows in the active workspace so that I can see at a glance where the window I'm looking for is. I imagine an IPC message kind of like:

$ niri msg layout "DP-1" 1
Column 1:
    blender

Column 2:
    kitty
    kitty

Column 3:
 * firefox

So that my bar can display the corresponding icons, e.g.

[YaLTeR]

Hmm, I'll consider this for #453

[jetjinser]

Hi, how does the event stream IPC make this possible? I'm also interested in the features discussed in this discussion: Displays a list of windows of the current workspace on the top bar.

I checked the current events and I have no clue on how to implement it. Any suggestions? Thanks!

[YaLTeR]

Yes, though at the moment not ordered. You get a list of workspaces with IDs, and a list of windows which have a workspace_id.

[jetjinser]

Ah, got it. Thank you!

But still, I would love a way to make an ordered list of windows possible, I hope it's a "nice to have" feature :)

[druskus20]

Yes, would be nice also if moving windows generates events in the EventStream, which currently, I believe, does not.
I have a use case in mind for a workspaces/windows indicator widget

[jakesarjeant]

Yeah, you're right. I'm working on a PR now which will hopefully add events for exactly those kinds of layout changes.

[jakesarjeant]

I've got some time now, so I'll try and put a PR together in the next few days. Shouldn't be that hard since #453 is already merged.

[jakesarjeant]

The most straightforward way I can think of to go about this would be to just add an ordered list of open window IDs to niri::ipc::Workspace, but that would be a breaking change to the current API, and it would cause a WorkspacesChanged event to be fired for every time a window is changed or reordered.

Alternatively (this is what I'm doing now), I could add a new Layout { workspace_id, columns } struct and corresponding LayoutChanged event. My only concern with this is that it doesn't really follow the "make invalid state irrepresentable" maxim, as it would theoretically be possible to have multiple layouts associated with the same workspace ID.

@YaLTeR do you have any input on this? Maybe you have a better idea since you know your codebase better than I do...

[YaLTeR]

FWIW, adding new fields to structs is not a breaking change. But changing the behavior of existing events in such a way that clients written against the previous version become logically incorrect would be a breaking change and we shouldn't do it.

I'm not yet sure how to best expose the rest of the layout over IPC. I don't think I want to do it just now necessarily. I know people also want window positions within a workspace, which I think could be used as a substitute here (you can sort by window X within a workspace). But I don't have a clear design for that either. I think it would make sense to add some kind of position_within_workspace: Option<(f64, f64)> to a Window, along with a WindowPositionsChanged { windows: Vec<Window> } event. This way it's forward-compatible with anything we might want to do in the future (can just set this to None if it doesn't make sense).

[jakesarjeant]

FWIW, adding new fields to structs is not a breaking change

It is for any rust users because a) rust requires every field to be mentioned in pattern matching and because b) AFAIK, serde doesn't allow unknown fields by default

I think it would make sense to add some kind of position_within_workspace: Option<(f64, f64)> to a Window, along with a WindowPositionsChanged { windows: Vec<Window> } event. This way it's forward-compatible with anything we might want to do in the future

Makes sense. I'll go ahead and mock up an implementation of that. Obviously, it's up to you to decide whether you want to merge it and when (I imagine there's some other things in the pipeline that might affect decision making with respect to this); I don't mind running my little fork on my personal setup until then and updating my bar when you decide how to go forward

[YaLTeR]

It is for any rust users

niri-ipc is explicitly not rust-semver-compatible for this reason

serde doesn't allow unknown fields by default

it does allow them

I imagine there's some other things in the pipeline that might affect decision making with respect to this

Yeah, we'll see

[jakesarjeant]

niri-ipc is explicitly not rust-semver-compatible for this reason

Ah, didn't know that

it does allow them

You're right. It seems my memory has failed me once again...

Yeah, we'll see

I suppose we will. I'll be watching with interest

[sommerper]

@jakesarjeant I currently use this as an alt-tab replacement.

#!/bin/bash

# Get window information and format it for fuzzel
window_list=$(niri msg --json windows | jq -r '.[] | "\(.id) | [\(.app_id)] - \(.title)"')

# Present the window list to fuzzel and get the selected window ID
selected=$(echo "$window_list" | fuzzel -d -p "Switch to: " | cut -d'|' -f1)

# If a window was selected, focus it
if [ -n "$selected" ]; then
    niri msg action focus-window --id $selected
fi

Maybe you can use that until something better comes along.

[jakesarjeant]

Thanks, but I feel like alt-tab style navigation sort of defeats the point of the spacial arrangement made possible by niri — I can navigate quite a lot more intuitively in niri; I just want something I can look to for a quick hint, especially when I'm using an application that I don't use very often