Currently niri creates a separate scope per spawn action matching the name of the executable.
So for example launching the non flatpak version of firefox through fuzzel will result in this firefox instance
to run under a scope name app-niri-fuzzel-<PID>.scope.
This can be problematic in combination with xdg-portal, which will use the scope name as a fallback for the
non accessible app id.
To solve this, this PR tries to mimic what systemd-sway does, moving toplevels to systemd scopes matching their app id.
In addition to moving the process it also add slices like systemd-sway offers. This allows to override resource
limits per app id slice.
The code is more a PoC and needs a major cleanup. The worst part is finding out all child pids that should also be moved to the new scope.
Currently
niricreates a separate scope per spawn action matching the name of the executable. So for example launching the non flatpak version offirefoxthroughfuzzelwill result in this firefox instance to run under a scope nameapp-niri-fuzzel-<PID>.scope. This can be problematic in combination withxdg-portal, which will use the scope name as a fallback for the non accessible app id.To solve this, this PR tries to mimic what
systemd-swaydoes, moving toplevels to systemd scopes matching their app id. In addition to moving the process it also add slices likesystemd-swayoffers. This allows to override resource limits per app id slice.The code is more a PoC and needs a major cleanup. The worst part is finding out all child pids that should also be moved to the new scope.