Control: reassign -1 chrome-gnome-shell,src:kservice Control: found -1 kservice/5.62.0-1
On Fri, 15 May 2020 at 22:08:35 +0800, Jason L. Quinn wrote: > Start of any QT application from the console produces the following chrome- > gnome-shell related error message: > > ==================== > kf5.kservice.services: The desktop entry file > "/usr/share/applications/org.gnome.ChromeGnomeShell.desktop" has Type= > "Application" but no Exec line > kf5.kservice.sycoca: Invalid Service : > "/usr/share/applications/org.gnome.ChromeGnomeShell.desktop" > ==================== >From codesearch, this seems to be coming from the kservice source package. It isn't clear to me whether this is a chrome-gnome-shell bug, a kservice bug, or a bit of both, so I'm assigning it to both packages for now. > The probable fix is that "Service" is probably intended instead of > "Application" for the Type. That type is not documented in the Desktop Entry Specification <https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html> although there is a note that it exists as a historical KDE-specific extension. It looks as though the intention is that this application is only runnable via D-Bus activation, and not via the traditional "run a child process" route. The Desktop Entry Specification allows this, although does not recommend it: The Exec key is required if DBusActivatable is not set to true. Even if DBusActivatable is true, Exec should be specified for compatibility with implementations that do not understand DBusActivatable. (note "should", not "must") Exec=/bin/false would presumably silence the warnings from kservice - but chrome-gnome-shell's .desktop file seems to be valid according to the specification, and it's here for integration with GNOME Shell (which we know *does* implement DBusActivatable), so in practice the Exec line will probably never be used anyway. So perhaps this is just a kservice bug, and kservice should be more tolerant? Another thing that might be considered a kservice bug is that random Qt applications probably shouldn't print diagnostic messages about unrelated .desktop files? That seems like a recipe for spamming warnings that the application's author cannot fix. If these messages appear at all, I would expect them to only be printed on request - perhaps something similar to GLib's g_debug(), which is a no-op unless you set the G_MESSAGES_DEBUG environment variable to a suitable value. I also can't help wondering whether chrome-gnome-shell should be OnlyShowIn=GNOME - I'm having a hard time seeing how a service to install GNOME Shell extensions could possibly be useful or relevant while not running GNOME Shell :-) smcv
