easyeffects
easyeffects copied to clipboard
wwmm
Add systemd user service
Although the change itself is simple I am afraid some users will enable this service and the switch in our menu at the same time. But what our menu setting does is creating an autostart file. In that case there will be two different places trying to autostart EasyEffects.
To avoid this we could query systemd via dbus and check if the unit is enabled/active, and then disable or enable the autostart option.
I think having systemd handle the process is overall more desirable, because it handles restarting in case of failure without having to have the window shown.
The problem of this solution is that we can't enable the service. It would be useful to enable and disable it on user choice, so maybe we could do it also for Flatpak users rather than trying to rely on libportal.
The problem of this solution is that we can't enable the service. It would be useful to enable and disable it on user choice, so maybe we could do it also for Flatpak users rather than trying to rely on libportal.
As far as I understand this wouldn’t be possible without poking a hole in the Flatpak sandbox. By design the only secure way to change things like this with Flatpak is through a portal. So there isn’t much benefit here at least for Flatpak as far as I can tell.
To avoid this we could query systemd via dbus and check if the unit is enabled/active, and then disable or enable the autostart option.
Besides what has been said by Digitalone1 and vchernin if we use systemd API it will become a dependency. I like systemd. I have no problems with it. But there will be people complaining about this move. And things will be harder for people trying to get EasyEffects running on other systems like FreeBSD. At least in the past PulseEffects was able to run on it.
Just a suggestion since it doesn't look like this has an intention to be merged. Perhaps rework it as a wiki addition instead?
Some users may discover it there and want that but not be familiar with how to configure the user service, so it could still be helpful.
Perhaps rework it as a wiki addition instead?
I do not see any problem in having a systemd service step by step in the wiki.
Besides what has been said by Digitalone1 and vchernin if we use systemd API it will become a dependency
Well, it could be an optional one.
Well, it could be an optional one.
Not without complicating even more some parts of our C++ code. As things are right now the setting Launch Service at System Startup already needs special handling for Flatpak through libportal. Supporting systemd too will only add more to the mess...
Been using the Flatpak version for a while and it's been working fine now. So the systemd service solution isn't necessary anymore.