cpupower-gui launches through CLI but fails to launch through .desktop file

[pshirshov]

When I launch cpupower-gui from terminal it works, when I click on it in the KDE Application Launcher I get the following message:

[unode]

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.

[pshirshov]

Probably it's a good idea to not use gapplication at all?

[jtojnar]

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 to propagatedBuildInputs

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.

[unode]

@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?

[jtojnar]

If I understand these correctly using gapplication is correct as it uses DBusActivatable.

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.

[unode]

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=.

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?

[jtojnar]

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.

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:

• it could patch the 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,
• the package could modify the user environment to put glib in it when installed. This is what propagatedUserEnvPkgs does but that breaks the expectation that Nix packages are self-contained and I think it is just awful.