Add niri compositor support

[abloch]

Summary

• Adds a WindowSystem implementation for the niri scrollable-tiling Wayland compositor
• Uses niri's IPC (niri msg -j focused-window / focused-output) to query window metadata and output geometry
• Registers niri in the compositor detection and import paths

Details

Niri supports the wlr-layer-shell protocol required by hints for overlay positioning. The implementation queries niri's JSON IPC for:

• focused window: pid, app_id, window size, tile layout info
• focused output: logical position, dimensions, scale

Window position is derived from tile_pos_in_workspace_view when available (multi-column layouts), falling back to computing position from output geometry and tile offsets for single-column layouts.

Files changed

• hints/window_systems/niri.py — new Niri(WindowSystem) class
• hints/window_systems/window_system_type.py — added "niri" to SupportedWindowSystems
• hints/hints.py — added niri to detection set and import match

Test plan

• Verified niri msg -j focused-window returns expected data (pid, app_id, layout with tile/window sizes)
• Verified Niri() class instantiates and returns correct extents on a live niri session (niri 25.11)
• Verified auto-detection finds niri process and routes to the correct class
• Ran hints -v — AT-SPI backend invoked, overlay coordinates passed correctly

[gazpachoking]

tile_pos_in_workspace_view seems to be null for anything but floating windows. The niri IPC doesn't give enough info to determine where the focused window is on the screen for tiled windows.

See #68 and niri-wm/niri#2381

[abloch]

Good catch, thanks! You're right — is only populated for floating windows. I've replaced the unreliable centering heuristic with a fallback to the full output geometry when is null. For tiled windows, hints will now scan the entire output rather than guessing an incorrect window position. Tracking the upstream fix at niri-wm/niri#2381 — once niri exposes tiled window positions we can tighten this up.

[AlfredoSequeida]

Hey! Thank you for adding niri and mango support!

So I know that #68 exists, and a lot of the niri implementation seems similar. I know that MR was not merged because there were some issues with gaps and other things. so a few questions.

1. Have those been addressed?
2. @abloch Maybe it would be best to merge have one MR for niri instead of two different implementations? So maybe we keep this MR for mango and use @Eddio0141 branch for the niri stuff if anything needs to change.

I know that has been sitting for a while mainly because of the issues I saw, but I'm ok with merging it as is knowing that there are limitations on the niri side that we need to wait for anyways.

[Eddio0141]

Yeah this is essentially same as my implementation (although not sure what mangowm is or how it relates to niri).

Their implementation is already a cleaned up implementation with the niri ipc limits in consideration, while mine still contains the attempt on calculating tiled window position which is pointless.

I say this one could be merged instead of mine.