Niri: Moving Floating Windows With Consume-or-Expel

Hey there, fellow Niri enthusiasts! Let's dive into a little discussion about window management and a specific quirk I've noticed with floating windows in Niri. If you're like me, you probably spend a good chunk of your time tweaking your tiling window manager to perfectly suit your workflow. And when it comes to window management, efficiency is key, right? Well, I've been exploring the consume-or-expel-window action and found that it doesn't quite behave as expected when dealing with floating windows. This might seem like a minor detail, but for those of us who rely on precise window control, it can be a bit of a roadblock. Let's break down what's happening and why it might be worth considering a slight adjustment to Niri's behavior in this regard.

The "Consume-or-Expel" Conundrum with Floating Windows

So, I've set up my keybinds in Niri to help me navigate and rearrange my windows efficiently. Specifically, I'm using Mod+Shift+H for consume-or-expel-window-left and Mod+Shift+L for consume-or-expel-window-right. My intention here is to quickly shuffle windows around on my screen. Now, when I'm working with tiled windows, these keybinds work like a charm. They grab a window and either expand the current one to consume its space or push it out to make room. It’s a neat way to manage space dynamically. However, the moment I switch focus to a floating window, things change. Suddenly, consume-or-expel-window-left and consume-or-expel-window-right do absolutely nothing. They just don't fire. This is where the unexpected behavior comes in. Many other window movement actions in Niri, such as variants of move-window-* and move-column-* (like the move-window-*-or-to-workspace-* I'm using), do manage to move floating windows around. They interact with them, repositioning them as expected. This leads me to believe that consume-or-expel-window-* should ideally do the same. The inconsistency is a bit puzzling. If other move actions can interact with floating windows, why not this one? It feels like a missed opportunity for unified control. I'm running Niri version 25.11, installed via Nixpkgs on NixOS 25.11, so this isn't an issue tied to an outdated version. It's a behavior I've observed consistently. The core of the issue lies in the expectation that a command designed to manipulate window positions should apply universally, regardless of whether the window is tiled or floating. The current implementation creates a silent failure for floating windows, which isn't ideal for a smooth user experience. It's about ensuring that the tools we have at our disposal are as versatile as our workflows. The fact that there isn't a direct equivalent of a "floating column" to expel a window from might be the technical reason, but surely there's a way to make the action of moving a floating window to an adjacent space work? This is the crux of the suggestion: making consume-or-expel-window-* behave consistently across both tiled and floating window states.

Why Consistency Matters: The Floating Window Gap

Let's delve deeper into why this behavior matters and what a more consistent approach could look like. The primary argument for modifying the consume-or-expel-window-* action to work with floating windows stems from the principle of least surprise and user experience. When users set up keybindings, they expect them to work predictably across different states of their window manager. As observed, other commands like move-window-*-or-to-workspace-* already demonstrate the capability to interact with and move floating windows. This existing functionality sets a precedent and an expectation. If Niri can move floating windows to different workspaces or reorder them in specific ways, it logically follows that an action named consume-or-expel-window should also be able to influence their position, albeit perhaps in a slightly different manner due to the nature of floating windows. The absence of functionality for floating windows essentially creates a gap in control. Users are forced to remember which actions work with which window types, or they might find themselves defaulting to mouse-based operations for floating windows, which defeats the purpose of a keyboard-centric tiling workflow. Making consume-or-expel-window-* functional for floating windows wouldn't necessarily be a breaking change. The action, as it currently stands, does nothing when a floating window is focused. Therefore, extending its functionality to manipulate floating windows would simply be adding behavior where there was none, rather than altering existing functionality in a way that might break user configurations. The concept of