-
-
Notifications
You must be signed in to change notification settings - Fork 662
Add pinned window support #3205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
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.
|
Updated to remove workspace switching animation and add window rules. Please try it out and see if you like the current design! |
|
I will probably play around with this later today and see how it is |
|
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. |
|
@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. |
|
Half screen wide terminal doesn't seem like a good use for the pinned that I have in mind? |
|
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. |
|
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 |
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
PinnedSpaceor 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
ToggleWindowPinnedaction, e.g.New window rules
open-pinnedto open a window pinned (orthogonal toopen-floating) andis-pinnedto match:New IPC action to toggle window pinned status:
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.