feat(oniri): Implement opt-in tiling layout mode

[1Naim]

Description

Introduce commandline arguments {-T, --tiling-layout} for a tiling mode,
where opening a second window in the workspace will collapse the first
one if maximized.

This brings more familiarity to users coming from a traditional tiling
environment, but still leveraging the infinite horizontal workspace.

Screenshots / Logs

recording_20260420_211817.mp4

Paste any relevant logs here (if you have some)

Fixed bug

Fixes "issue_URL" (if any)

Addressed feature request

Closes "issue_URL" (if any)

[1Naim]

need to update docs... can you take care of that?

[Antiz96]

need to update docs... can you take care of that?

Yeah I will, no worries :) Thanks!

[1Naim]

Hmmm, not sure why opening nautilus for the first time doesn't trigger any actions. It works for subsequent opens, and also works with the python script. Let me check why this is the case.

[1Naim]

so its because of fefb66c, although I'm not too sure why. It could be a Nautilus quirk.

[1Naim]

[2026-04-20T14:24:07Z DEBUG oniri] Trigger Event: Window Opened
Window opened: id=55, title=Loading…
[2026-04-20T14:24:07Z DEBUG oniri::size_compare] Window 55: out_w=1706, out_h=1066, tile_w=838, tile_h=1011, tol_w=150, tol_h=150
[2026-04-20T14:24:07Z DEBUG oniri::size_compare] Window 55: width_ok=false, height_ok=true, maximized=false
[2026-04-20T14:24:07Z INFO  oniri::maximize_window] Maximized window 55
[2026-04-20T14:24:07Z DEBUG oniri] Trigger Event: Window Opened
Window opened: id=55, title=Home
[2026-04-20T14:24:07Z DEBUG oniri::size_compare] Window 55: out_w=1706, out_h=1066, tile_w=838, tile_h=1011, tol_w=150, tol_h=150
[2026-04-20T14:24:07Z DEBUG oniri::size_compare] Window 55: width_ok=false, height_ok=true, maximized=false
[2026-04-20T14:24:07Z INFO  oniri::maximize_window] Maximized window 55

Yeah I think it is, I guess the first event's maximize seems to be deferred until it finished loading so it ends up being negated.

[1Naim]

diff --git a/src/main.rs b/src/main.rs
index fe8c74f95a08..ae693fecffb4 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -86,6 +86,10 @@ fn main() -> anyhow::Result<()> {
                     continue;
                 }
 
+                if window.app_id.unwrap_or_default() == "org.gnome.Nautilus" && window.title.unwrap_or_default() == "Loading…" {
+                    continue;
+                }
+
                 debug!("Trigger Event: Window Opened Or Changed");
 
                 let id = window.id;

This works, but its more of a hack than anything. Any ideas on how to solve it?

edit: Okay, one idea is to move all the logic outside of the match arm and handle it separately like in the python script. Not sure how elegant this is though

[Antiz96]

This works, but its more of a hack than anything. Any ideas on how to solve it?

No, not at the moment... I'm not using Nautilus myself but given what you describe, it indeed seems like a race condition with Nautilus first loading. Maybe adding a slight delay to the maximize action to hopefully cover it? Although might probably be even more of a hack?

edit: Okay, one idea is to move all the logic outside of the match arm and handle it separately like in the python script. Not sure how elegant this is though

Hum, yeah. Although probably more elegant then a hack specific to Nautilus? I don't know...

[Antiz96]

I don't necessarily mind one hack for a specific application if this is a somewhat isolated case for what it's worth. But I'd ideally like to avoid applying too much downstream hacks to workaround such upstream quirks (assuming it's indeed an upstream thing).

[1Naim]

I don't necessarily mind one hack for a specific application

I decided to go with this for now, since the suggestion I made above would require rewriting quite a bit and potentially make things uglier.

[Antiz96]

I don't necessarily mind one hack for a specific application

I decided to go with this for now, since the suggestion I made above would require rewriting quite a bit and potentially make things uglier.

Alright, fine by me.
Actually, as far as I understand, this should be fixed once the niri IPC will eventually support an action to set the maximized state rather than toggling it (see #3). There's indeed an underlying race condition causing two "maximized" action being triggered, but unfortunate / unpredictable consecutive actions like that are only a problem because the IPC is limited to a toggling action at the moment. Correct?

[1Naim]

There's indeed an underlying race condition causing two "maximized" action being triggered, but unfortunate / unpredictable consecutive actions like that are only a problem because the IPC is limited to a toggling action at the moment. Correct?

Yeah. If maximizing noops when the window is already maximized, then this shouldn't be an issue.

[Antiz96]

There's indeed an underlying race condition causing two "maximized" action being triggered, but unfortunate / unpredictable consecutive actions like that are only a problem because the IPC is limited to a toggling action at the moment. Correct?

Yeah. If maximizing noops when the window is already maximized, then this shouldn't be an issue.

Alright, so the race condition is obviously an unfortunate issue but it only actually hits us because of a limitation from the niri IPC then. Hopefully this will be addressed at some point (the related PR are already opened on the niri upstream side, I'll send a friendly ping there).

[Antiz96]

May I ask if we can ship 9ff707c in a separate PR? 👼

It's not actually linked to this the new tiling mode feature, I'd rather have it being shipped as a separate "fix:" commit if you don't mind 🙏

[1Naim]

Another thing I noticed is that this won't work well for workspaces with tabbed columns. I'm not sure how to go about doing that. I guess its low priority because this is opt-in and tabbed columns don't necessarily have to be used anyway.

[Antiz96]

Another thing I noticed is that this won't work well for workspaces with tabbed columns. I'm not sure how to go about doing that. I guess its low priority because this is opt-in and tabbed columns don't necessarily have to be used anyway.

Ah right good catch, thanks for the heads up. I don't think it's worth blocking this new (optional) feature for this indeed. If we ever find an elegant fix for that later, that's great. But let's ship this anyway :)

[Antiz96]

Thanks once again for the great work. Really appreciated!
The new tiling mode feature is pretty neat, I'll probably use it myself 😄