XDP without systemd

[QaidVoid]

The current implementation only sets up D-BUS interface required for XDP-gnome to work if the compositor is run as systemd service. systemd isn't a requirement of XDP-gnome, so maybe systemd checks can be dropped (or, check for D-BUS session instead)? This would allow XDP to function if the compositor is running as a D-BUS session.
And, maybe the compositor can itself set XDG_CURRENT_DESKTOP and XDG_SESSION_TYPE environment vars, which would allow to simply use dbus-run-session niri to start the compositor instead of having to rely on wrapper script.

I've tested this on system without systemd and it appears to work fine.

[YaLTeR]

Hm. Does dbus-run-session have some way to tell the binary it runs "you're the new session", similar to having a systemd NOTIFY_SOCKET? Niri needs that because it should only set some environment variables and start D-Bus services if it is the new session binary, and not when running as a nested window or on a different TTY on its own. I could add a CLI flag but I'd much prefer this to be automatic.

[YaLTeR]

Although, thinking about it, maybe I should replace the current check with that new CLI flag. For example right now it's awkward to make a systemd service for a nested niri. Not that I know why anyone would want that, but still.

[YaLTeR]

This is a bit confusing:

• When you run niri as a systemd service "from a login manager" you want to set systemd env (so systemd services can see it) and dbus env (so dbus activated stuff sees it)
• When you do dbus-run-session niri "from a login manager" you want to only set dbus env, but not systemd (since there's no systemd socket to notify, it's not like programs can adequately depend on niri having started up anyway)
• When you do dbus-run-session niri nested / on its own, you also want to set only dbus env
• When you run niri as a specially-written nested systemd service you want to set neither but it's nice to signal systemd activation
• When you run dbus-run-session niri as a specially-written nested systemd service you want to set dbus env but not systemd env, but it's nice to signal systemd activation <= this case will break with a --session flag because it'll assume it needs to set systemd env too
• When you run niri on its own you want to set neither

[QaidVoid]

Does dbus-run-session have some way to tell the binary it runs "you're the new session", similar to having a systemd NOTIFY_SOCKET?

DBUS_SESSION_BUS_ADDRESS, but it can't be unset, unlike NOTIFY_SOCKET. Maybe check if DISPLAY or WAYLAND_DISPLAY exists to figure out if it's running on nested window. If they're not set but DBUS_SESSION_BUS_ADDRESS is, setup dbus env vars and start dbus services. It means no nested session, though. This approach would work on other init systems except systemd. Since DBUS_SESSION_BUS_ADDRESS is setup by systemd on login, running niri on its own will still provide DBUS_SESSION_BUS_ADDRESS.

So, flag might be better.. If --session flag is set and DBUS_SESSION_BUS_ADDRESS is present, setup dbus env and start dbus services.