Skip to content

Conversation

@my4ng
Copy link
Contributor

@my4ng my4ng commented Jan 5, 2026

This attempts to implement #932 based on #932 (comment), by pinning windows to a monitor across its workspaces. More concretely, this means all pinned windows are moved to the new workspace on switching, without introducing a new PinnedSpace or duplicating windows across workspaces.

EDIT: Windows are first moved to a temporary space of the monitor, and fully moved to the new workspace only after animation is done (to appear stationary).

Since pinned windows are just normal windows, navigation between windows remains the same as before. The disadvantage is that pinned windows only appear on the focused workspace in overview, and pinned windows are animated alongside the new workspace on workspace switching.

Currently, as long as the pinned windows are on the active workspace and floating, regardless of their status when pinned, they will be moved to the newly switched workspace, otherwise they will be unpinned.

EDIT: Pinned windows will keep their latent pinned status even if they are not floating on workspace switch, though they won't be carried to the new workspace. As soon as they become floating, they will remain fixed to the monitor on workspace switch.

Windows can be pinned via the ToggleWindowPinned action, e.g.

binds {
    Mod+P { toggle-window-pinned; }
    ...
}

New window rules open-pinned to open a window pinned (orthogonal to open-floating) and is-pinned to match:

window-rule {
    ...

    open-pinned true
}

window-rule {
    match is-pinned=true

    ...
}

New IPC action to toggle window pinned status:

niri msg action toggle-window-pinned
niri msg action toggle-window-pinned --id <ID>

NOTE: This is only a solution to pinned windows, but IMO much, much simpler than alternative designs. Please check it out and provide feedback on the design/pinning behaviour logic if you are interested.

my4ng added 3 commits January 5, 2026 23:14
Pinned windows should now remain stationary on output during workspace
switching by removing it from the previously active workspace into a
temporary monitor space that is only added into the switched workspace
after the animation is done.

During this transient phase, some actions on the pinned windows may not
work, since they are not part of a floating/scrolling space of any
workspace.
@my4ng
Copy link
Contributor Author

my4ng commented Jan 17, 2026

Updated to remove workspace switching animation and add window rules. Please try it out and see if you like the current design!

@Sempyos
Copy link
Contributor

Sempyos commented Jan 18, 2026

I will probably play around with this later today and see how it is

@YaLTeR
Copy link
Owner

YaLTeR commented Jan 25, 2026

I haven't taken a look at this, but just to set expectations: I will definitely want to explore adding a separate pinned floating space first. My idea is to try to have pinned windows retain their position in the Overview, kinda like top and overlay layer-shell surfaces. As I understand, this is what you want for many usecases.

@my4ng
Copy link
Contributor Author

my4ng commented Jan 25, 2026

@YaLTeR I should have updated the comment about the overview: the pinned windows appear in overview, but only on the active workspace. This is by design, since, in terms of implementation, the pinned windows can be easily moved to the temporary space on overview open just like on workspace switch.

My rationale is quite simple. If I have a pinned PnP and a pinned terminal that take half the space of the monitor, I would like to see what they would be covering on other workspaces in the overview. It doesn't make sense to display them on all workspaces that simply obstruct the overview.

@YaLTeR
Copy link
Owner

YaLTeR commented Jan 25, 2026

Half screen wide terminal doesn't seem like a good use for the pinned that I have in mind?

@my4ng
Copy link
Contributor Author

my4ng commented Jan 25, 2026

I meant two or three pinned windows that may sum up to a substantial part of the screen space. Placing them across the overview feels obstructive to me, but that is just an opinion. If people do want that, it can be easily changed.

@YaLTeR
Copy link
Owner

YaLTeR commented Jan 25, 2026

Covering too much space with pinned windows isn't really among the primary usecases I've been considering for designing niri built-in pinned windows. I don't think this usecase should be blocking

Anyway feel free to leave this PR, idk when I'll get to pinned windows anyway

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants