Open pshirshov opened 4 months ago
The issue is that the .desktop
file has Exec=gapplication launch org.rnd2.cpupower_gui
.
This went unnoticed on my end because I have glib
installed system-wide.
However I'm not familiar enough with the Gnome ecosystem to tell if it's ok to add glib
to propagatedBuildInputs
or if a different direction should be taken.
Will try to ask around/investigate.
Probably it's a good idea to not use gapplication at all?
The app is DBusActivatable
so the Exec
should not be used at all according to spec https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html#recognized-keys
if it's ok to add
glib
topropagatedBuildInputs
That would not do anything to fix. Propagation only makes the input available in build environment of the packages that depend on the propagator. It is up to the build script to do anything with it, which most won't.
It would be possible to patch the desktop file to use absolute path to gapplication
but that has its own issues. And again, the Exec
should not be used.
@jtojnar From the link you shared:
A boolean value specifying if D-Bus activation is supported for this application. If this key is missing, the default value is false. If the value is true then implementations should ignore the Exec key and send a D-Bus message to launch the application. See D-Bus Activation for more information on how this works. Applications should still include Exec= lines in their desktop files for compatibility with implementations that do not understand the DBusActivatable key.
From https://developer-old.gnome.org/gio/stable/gapplication-tool.html
gapplication can be used to start applications that have DBusActivatable set to true in their .desktop files and can be used to send messages to already-running instances of other applications.
If I understand these correctly using gapplication
is correct as it uses DBusActivatable
.
However you mentioned that patching the absolute path to gapplication
has its own issues.
Is there any other option?
If I understand these correctly using
gapplication
is correct as it usesDBusActivatable
.
I meant that Exec
should not be used by the launcher. The launcher should use ask D-Bus daemon to start the app and ignore Exec=
.
I would expect Plasma to support D-Bus activation since it is mentioned in KDE docs. Maybe it checks if program in Exec
exists even if it would use D-Bus activation? Try copying the desktop file to ~/.local/share/application
and removing the Exec
line to verify.
However you mentioned that patching the absolute path to
gapplication
has its own issues. Is there any other option?
Having user install glib
manually. But that would have to be communicated somehow.
I meant that
Exec
should not be used by the launcher. The launcher should use ask D-Bus daemon to start the app and ignoreExec=
.
This sounds like something that would need to be fixed in the launcher, not here.
As I understood the docs above, the .desktop
file is correct and having gapplication
as the command will make sure that the dbus activation takes place even when the launcher uses the command from Exec
. gapplication
is a fallback compatibility layer.
Having user install
glib
manually. But that would have to be communicated somehow.
glib
is already in buildInputs
. If we patch the .desktop
file to refer to this dependency, won't this be automatically handled? It won't be in PATH
but the dependency will be on the system so referring to it with full path should be fine. I thought this is how it is handled in other cases where we want to avoid searching PATH
.
Or am I missing something here?
glib
is already inbuildInputs
. If we patch the.desktop
file to refer to this dependency, won't this be automatically handled? It won't be inPATH
but the dependency will be on the system so referring to it with full path should be fine. I thought this is how it is handled in other cases where we want to avoid searchingPATH
.
No. Inputs only make it available during build. It is up to the builder to ensure the dependencies are available at runtime – by patching the source code, passing appropriate build flags or modifying the build artefacts. For example, the generic builder does this for inputs that are ELF libraries, buildPythonPackage
does this for Python packages that are in propagated inputs…
The issue is that there is no good option for what builder could do:
Exec=
path to be absolute but then you get issues with GC when menu editor/autostart tool copies it, see https://github.com/NixOS/nixpkgs/pull/68035#issuecomment-950292530,propagatedUserEnvPkgs
does but that breaks the expectation that Nix packages are self-contained and I think it is just awful.
When I launch
cpupower-gui
from terminal it works, when I click on it in the KDE Application Launcher I get the following message: