Created attachment 121307 [details] app name missing SUMMARY The battery applet shows the name of Qt5 apps suppressing the power management, but the same does not occur with gtk3 apps. STEPS TO REPRODUCE 1. play an audio file with any of the following gtk3 apps: gnome mpv, totem video player, rhythmbox music player. 2. while the app plays the file, click on the battery icon in systray 3. OBSERVED RESULT As we can see in the attached screenshot, the popup says that the power management is currently suppressed, but the app name is missing. EXPECTED RESULT The battery applet indicates which app is currently suppressing the power management. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.16.2 KDE Frameworks Version: 5.59.0 Qt Version: 5.13.0
Created attachment 121308 [details] App name is shown when Dragon player suppresses the power management
Can you run the following command before starting a video and see what it calls? dbus-monitor interface=org.freedesktop.ScreenSaver
Can confirm. Runs through the xdg desktop portal. Yet another way for apps to post inhibitions, this is ridiculous. Will investigate.
(In reply to Kai Uwe Broulik from comment #2) > Can you run the following command before starting a video and see what it > calls? > > dbus-monitor interface=org.freedesktop.ScreenSaver signal time=1562163117.974544 sender=org.freedesktop.DBus -> destination=:1.66 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.66" signal time=1562163117.974627 sender=org.freedesktop.DBus -> destination=:1.66 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost string ":1.66"
App shouldn't be using the portals for when it's not a sandboxed app. I don't get an app_id from it as a result.
(In reply to Kai Uwe Broulik from comment #5) > App shouldn't be using the portals for when it's not a sandboxed app. I > don't get an app_id from it as a result. Is this a packing issue? Or should I report this to the devs of each app?
reported to Gnome devs. https://gitlab.gnome.org/GNOME/totem/issues/378 Apparently it's a xdg-desktop-portal-kde issue. Comment from the link above: "totem uses gtk_application_inhibit(), which is ultimately implemented in gtk/gtkapplication-dbus.c (look for inhibit in there). This code then contacts the portal, because you're not running the application under gnome-session, or xfce-session. The portal code in xdg-desktop-portal then passes on the application's data to the per-desktop portal, in this case xdg-desktop-portal-kde. It doesn't look like the KDE code passes on the app_id: https://github.com/KDE/xdg-desktop-portal-kde/blob/master/src/inhibit.cpp The GTK version does: https://github.com/flatpak/xdg-desktop-portal-gtk/blob/master/src/inhibit.c#L122 The problem is in one of glib, xdg-desktop-portal, or xdg-desktop-portal-kde. It's not in totem."
We also pass the application id in xdg-desktop-portal-kde, but as Kai said, this is supposed to be used only in sandbox (Flatpak, Snap). If the app use it outside, then the application id will be empty.
Is it possible that something is wrong with glib or xdg-desktop-portal? Totem from flathub is not affecred by this issue.
Any application from Flathub will work just fine, that's because it's running in Flatpak (sandbox) and that way xdg-desktop-portal will properly send app_id. If you run it as a regular app, not in Flatpak, then app_id will be empty, as the app cannot be identified by xdg-desktop-portal.
The information is taken from .flapak-info file which exists for each Flatpak instance. See https://github.com/flatpak/xdg-desktop-portal/blob/master/src/xdp-utils.c#L364.