Arch Linux User Repository

@tam1m; ah fair enough. Because the desktop file was created in-line in this PKGBUILD and not coming from upstream I thought it was custom wrapping logic. In that case I'll probably make a ticket upstream.
Maybe the PKGBUILD should be changed to use the upstream desktop file then though?

So what do you really gain from the service? In the current state of pipeweaver, I'd argue, having a service that open the webinterface is weird.

On my end it never opened the webinterface initially, it only ran the service/daemon. It opening the webinterface only happened if the daemon was already running. I do suppose I'm missing out on a tray icon then, but I wasn't using that anyway.

@Omar007

The desktop file is just what upstream has decided it is supposed to be. see: https://github.com/pipeweaver/pipeweaver/blob/main/daemon/resources/desktop/pipeweaver.desktop

Currenlty running pipeweaver-daemon will always start the daemon, open the webinterface and add its icon to the system tray. So the upstream desktop file already does what you want it to do. which is open the webif. When pipeweaver is already running, the desktop file and tray icon just do that and nothing else. If it's not running, it brings up the daemon and opens the webinterface. Nothing we can do about that.

So what do you really gain from the service? In the current state of pipeweaver, I'd argue, having a service that open the webinterface is weird. I don't think users would expect a daemon service opening ui elements.

Generally I'd agree, that the two should be seprated. I'd suggest disussing that upstream tho. Maybe open a ticket there with your suggestion.

Would it be an idea to provide a systemd user unit for the daemon instead (or alongside) the desktop file?

I personally expected the desktop file to open the Pipeweaver URL (or open a stand-alone client application when/if it exists), not for it to (also) be the way to start and manage the daemon itself. Relying on/using a desktop file to manage the state of a daemon is very weird imo.
I ended up with the following user unit to manage the daemon instead:

[Unit]
Description=Pipeweaver Audio Manager
Wants=pipewire.socket
ConditionUser=!root

[Service]
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
Type=simple
ExecStart=/usr/bin/pipeweaver-daemon
Restart=on-failure
Slice=session.slice

[Install]
WantedBy=default.target

Tbh, it can probably be constrained further (e.g. more constrained SystemCallFilter) but this seemed like a good starting point.

(if included in the package it should be installed to /usr/lib/systemd/user)

I personally also changed the desktop file to only open the default URL as I don't want to potentially run the daemon outside of it's unit:

[Desktop Entry]
Name=Pipeweaver
GenericName=Audio Mixer
Comment=An Audio Mixer built upon Pipewire
Exec=xdg-open http://localhost:14565
Icon=pipeweaver
Terminal=false
Type=Application
Categories=AudioVideo;Audio;Mixer;
StartupNotify=false

Though if you don't care about that, Pipeweaver does detect an already running daemon and then just opens the web interface so for opening the interface itself it is not strictly required to change it..