Floating windows

[YaLTeR]

So fed up with scrolling tiles. I'm converting niri into a floating WM.

Just kidding. This is a floating window layout on top of the scrollable-tiling layout. The floating layout does not scroll.

Most of the basics are done, though plenty of work remains; I'm focusing on this as time permits. No need to list every missing thing quite yet, but feel free to post if something is particularly annoying you so I can prioritize it.

Windows will auto-float if they have a parent (e.g. dialogs) or fixed size (e.g. splash screens). Otherwise, you can use the new toggle-window-floating bind or right click during an interactive move. You can also use the new open-floating true/false window rule to either force auto-float a window on open or disable auto-floating for a window.

Use switch-focus-between-floating-and-tiling (taking name suggestions) to switch between the two layouts. When focused on the floating layout, binds (like focus-column-right) will operate on the floating windows.

Resolves: #122

[alicealysia]

I'd rename it to:
toggle-floating-focus

As always, your timing for testing a new feature has lined up with me needing it haha.

[YaLTeR]

Is that clear enough of a name? I feel like it might not be, especially to people new to standalone WMs.

[alicealysia]

Hmmm. You're right, I think your name is much clearer. The only motivation on my end is brevity. Maybe I should finally try making a settings app.

[20after4]

FWIW this is working well for me.

I kind of expected the floating layer to be shared between workspaces. I'm not sure why I had that expectation and I don't have a good argument for why floating should be global as apposed to workspace specific.

[quadbyte]

Working great here too.

What about "focus-next-layout" instead of "switch-focus-between-floating-and-tiling" ?

[YaLTeR]

FWIW this is working well for me.

Good; any missing things that you bump into more frequently than others?

I kind of expected the floating layer to be shared between workspaces. I'm not sure why I had that expectation and I don't have a good argument for why floating should be global as apposed to workspace specific.

I'm planning to add that separately later for always-on-top/pinned picture-in-picture and such windows.

What about "focus-next-layout" instead of "switch-focus-between-floating-and-tiling"

Hm, might be easy to confuse with the keyboard layout binds.

[20after4]

Good; any missing things that you bump into more frequently than others?

The main thing I really miss with niri the traditional alt-tab behavior that will switch window focus in a MRU stack. That isn't really related to this PR though.

Only other thing I can think of is a suggestion for positioning multiple subsequent windows onto the floating layer:

It seems like the default placement of floating windows is to center the window on screen and multiple windows get stacked in the same position. If I launch, for example, 2 calculator windows, using a window rule to make them start floating, then they are positioned exactly on top of each other. It might be nicer if each subsequent window had a slight offset down and to the right, so that they arrange in a "cascade" layout or something.

Thinking it through, however, there are probably all kinds of edge cases if you start down the rabbit hole of trying to select optimal placement for various window types and sizes. Centered is probably the safest option and my suggestion might only be applicable to small windows like calculator.

[YaLTeR]

The main thing I really miss with niri the traditional alt-tab behavior that will switch window focus in a MRU stack. That isn't really related to this PR though.

Yeah that can be separate with a separate discussion like which windows it should include across monitors/workspaces/tiling/floating.

It seems like the default placement of floating windows is to center the window on screen and multiple windows get stacked in the same position. If I launch, for example, 2 calculator windows, using a window rule to make them start floating, then they are positioned exactly on top of each other. It might be nicer if each subsequent window had a slight offset down and to the right, so that they arrange in a "cascade" layout or something.

Thinking it through, however, there are probably all kinds of edge cases if you start down the rabbit hole of trying to select optimal placement for various window types and sizes. Centered is probably the safest option and my suggestion might only be applicable to small windows like calculator.

Yeah, I thought about it a bit and came to the conclusion that there are probably edge cases. Could do some more research into what Mutter does.

[YaLTeR]

Alright, I finished everything I wanted, save for a few minor things that I'll do in the next few days. This PR is ready for general testing. Please report any bugs, issues, annoyances, or missing things. I'll consider them either for this PR or for further work.

[phisch]

Description above says it sets the height if it is opened as floating, but this rule doesn't apply to only floating windows.

[YaLTeR]

I actually intend to make it apply to all windows; currently it should only like half apply to scrolling ones I think

[JaCoB1123]

I started using the branch yesterday and I'm already really happy with the feature. Some pop-ups that have been annoying me since switching to niri, are now behaving nicely. 👍 Thanks a lot 😀

What I'm missing is a way to set the default position for a popup. For example the Picture-in-Picture window of firefox always opens centered and I'd prefer it in the lower right corner. Ideally the position would still use the parent window's screen though (so no absolute coordinates across all my monitors).

Also thumbs up for the documentation. I found everything I needed and the examples are very relevant. 👍

[YaLTeR]

@JaCoB1123 Thanks! Default floating position has actually been requested yesterday by @phisch too. The commits I just pushed have a new default-floating-position window rule for that. There's no absolute coordinates.