i think this is thinkable.

we need floating window in wm , because we need to see some window always fixed, instead of scroll away or disappeared.

add one floating layer , is one solution. but i think there is another:

• add a fix/sticky property.

window who has this property, always display at the same position while scrolling.

and we could have these two type of fix/sticky:

• sticky in the workspace
• stikcy in the screen (all workspaces)

maybe this is more simple than floating layer in coding.

using examples

• chat window, need to be fixed/sticky in all workspaces.
• dev doc window, with 5 editor windows, need to be sticky in workspace while focus editor window.
• video playing window, need to be sticky in workspace/screen while doing some other work.

For sticky in workspace there's a curious suggestion in #149. For globally sticky, that's how I imagine the floating layer to work in niri. Thanks for the examples, they will be good to keep in mind.

A global, floating layer would be really useful for Firefox's Picture in Picture video, and other similar things.

I'm not sure if this is possible, but I would love to see two features:

1. New/independent floating windows default to centered in display, can be moved around. They stay in place when we pan the view left/right.
2. Child floating windows (like dialog popups) are centered on their parent window, and move with their parent when we pan the view left/right.

The 2. will only make sense for modal dialogs which block input to the parent window, however the modal state is not actually communicated in any of the stable Wayland protocols. It's in private gtk-shell and KDE, and there are MRs into wayland-protocols to make it into a public protocol.

one use-case for which i would like to make a window rule to make a window float is modal dialogs of keepassxc's browser extension.
when using the browser extension to select a credential, the native application will open a modal dialog asking the user to grant permission.
presently, using niri this dialog is opened next to keepassxc, as a new tiled window.
from a UX perspective, this is unfortunate since i do not even have any indication that such a window has opened.

i would prefer to see that addressed by allowing to make a window float from the window rules.
additionally, in hyprland i used a workspaces bar plugin that could visually mark workspaces wanting attention (which they called 'urgent'). i feel this was also useful to attend me to newly opened windows wanting attention as well (in case they lack focus, i.e. when no floating window rule has been created for them).

Yeah, floating would make sense for this.

when using the browser extension to select a credential, the native application will open a modal dialog asking the user to grant permission.
presently, using niri this dialog is opened next to keepassxc, as a new tiled window.

That means the dialog sets keepassxc itself as its parent. So as far as niri thinks, keepassxc running in the background randomly opened a dialog, so it shouldn't steal focus.

attention

This depends on #30

add one floating layer , is one solution. but i think there is another:

• add a fix/sticky property.

I would like this as a window rule for stuff like launchers (in my case albert, which currently gets treated as just another window)

I am currently trying to use albert launcher too with niri and I am facing the same issue as @nougatbyte
But maybe it should be handled by their team since fuzzel, wofi, etc actually work?

It could, yeah. It's one of the purposes of layer-shell after all.

Thanks for pointing me in the right direction, I've transmitted the info to them. (I love niri btw <3)

I am currently trying to use albert launcher too with niri and I am facing the same issue as @nougatbyte But maybe it should be handled by their team since fuzzel, wofi, etc actually work?

Its not an overlay but I use this in a bashscript to call albert:

#!/bin/bash
albert show
niri msg action center-column

I'm interested in working on this issue

I'm interested in working on this issue

Hey, so adding a floating layer will need larger architectural and design considerations; I can't really say how exactly it should look in the code without trying to implement it myself. In broad strokes:

• the floating layout logic and actions should live inside Layout, together with the scrolling layout, so that they are fully testable, like the scrolling layout actions.

• floating windows live in the same global coordinate space as the monitors. There are no workspaces or anything (at least for the first implementation for simplicity).

  This is the global Space with the monitors and the mouse cursor. It will probably be convenient to add Smithay floating Windows to this Space because it handles output overlap area computation. However, I am not sure whether it is best to try to add Windows to that Space directly, or to have a copy of that Space inside Layout, or even to avoid using a Space altogether and deal with coordinates manually. The latter might turn out to be the best option to avoid leaking and intertwining between Layout and the outside code.

In case you want to start with something less abstract, you could try to implement mouse window resizing (both per client request, i.e. dragging from a corner of a window, and with Mod+Right Click). The rule of thumb on how that should work is: the window edge that is being resized should end up at the spot where the mouse pointer is (which means that always-centered columns will resize twice as fast horizontally, since their other edge will move in unison). As a start, the view can be restricted from scrolling during a mouse resize.

Has any progress been made on this? There are some applications that I would like to be in a window mode or not be set at full height. For example using a calculator app, etc

It would be nice if the floating layer could be scrollable too (either together or separately from the normal layer)

The interactive move PR is fairly good progress

Hoping this comes soon - some really small dialog windows shouldn't move everything to the left, example: master passwd dialog in firefox. Just some window rules will do it.

Just to note that Zoom screen-sharing seems to do a few tricks with windows to implement things like the screen-sharing controls at the top of the screen, and tiling seems to interfere quite a lot with this.

Those tricks can't work reliably on Wayland in general since windows, floating or not, don't know and can't control their position on screen. An overlay like that could use layer-shell instead.

But maybe it'll happen to work somehow anyway, we'll see.

Those tricks can't work reliably on Wayland in general since windows, floating or not, don't know and can't control their position on screen. An overlay like that could use layer-shell instead.

In this specific case, I think Zoom needs/expects the controls to be in a floating window, and then "sticks" them to the top/bottom of the screen.
Under PaperWM, I seem to remember solving this with a Window rule that makes all Zoom windows floating — but that's a fair while ago, so I may be misremembering.

But maybe it'll happen to work somehow anyway, we'll see.

Stranger things have happened! 😉
And def. happy to wait and see.

Hey everyone, after a ton of work the floating window PR #871 is ready for general testing. Please give it a try and report any bugs, issues, annoyances, or missing things (comment on the PR itself). I'll consider them either for that PR or for further work.

Uhhh welp I just commented on the wrong issue/repo/project/everything, sorry everyone who got a notification of that. That’s what I get for having too much tabs open I guess.