wwmm
Global Shortcuts don't work under some conditions (GNOME)
EasyEffects Version
8.0.4 (gafa3c48c1)
What package are you using?
AUR (easyeffects-git)
Distribution
Arch Linux
Describe the bug
Global shortcuts don't do anything under some conditions, even though they're correctly registered:
$ dconf dump /org/gnome/settings-daemon/global-shortcuts/
[/]
applications=['com.github.wwmm.easyeffects']
[com.github.wwmm.easyeffects]
shortcuts=[('global bypass', {'shortcuts': <['<Control><Alt>e']>, 'description': <'global bypass'>}), ('microphone monitoring', {'shortcuts': <['<Control><Alt>i']>, 'description': <'microphone monitoring'>})]
Foremost, they never seem to work when EasyEffects is started from a terminal. Yesterday I had a probably related bug, which I'm not able to reproduce unfortunately: After starting easyeffects from the terminal, GNOME prompted me to recreate the global shortcuts, but actually used the terminal's application ID (com.mitchellh.ghostty) instead of com.github.wwmm.easyeffects. All this makes me think registering the application with the portal doesn't work as it should.
There's an additional issue I only have with the main branch of xdg-desktop-portal: When EasyEffects starts in the first ~10s of the user session (e.g., through the autostart entry), global shortcuts work for a few seconds, and then stop working all of a sudden. Restarting from the desktop file doesn't change anything. But when starting EasyEffects later in the session, they reliably work, even after multiple restarts.
The latter bug does not happen with stable release 1.20.3 of xdg-desktop-portal, so this is possibly just an upstream regression. But I want to make sure EasyEffect's doesn't do anything funky before reporting this, and maybe with some more insight about what is going sideways here.
Expected Behavior
No response
Debug Log
No response
Additional Information
No response
Foremost, they never seem to work when EasyEffects is started from a terminal.
This is a known limitation. Take a look at the discussion at #3834. Xdg portal is designed in a way that this functionality requires the application to be started from the desktop file. As far as I know there is nothing we could do about it.
All this makes me think registering the application with the portal doesn't work as it should.
Or maybe this could help. It is hard to find code examples of this functionality. And I think the ones I found did not use this call. But considering its docs explain that additional attempts to register result in error one important point is if the calls we have to do are not trying to register too.
The latter bug does not happen with stable release 1.20.3 of xdg-desktop-portal, so this is possibly just an upstream regression. But I want to make sure EasyEffect's doesn't do anything funky before reporting this, and maybe with some more insight about what is going sideways here.
All I can say is that I have never seen this in the stable xdg release too. So it feels like a xdg regression indeed.
At this moment it seems this protocol needs quite a lot of improvements. There is too much difference in how different desktop behaves when global shortcuts are used. Here on KDE they seem totally fine as long as the app is started through a desktop file. On other desktops it seems global shortcuts not always work well.
Now (on 6eeb889) global shortcuts don't work at all for me, even with the xdg-desktop-portal 1.20.3 release, and starting through a desktop file. This is logged when started from a terminal:
easyeffects: global_shortcuts.cpp:90 D-Bus session for GlobalShortcuts created.
easyeffects: main.cpp:165 XDG Global Shortcuts experimental feature is enabled for this session.
easyeffects: global_shortcuts.cpp:172 Successfully bound global shortcuts without session (fallback)
qt.qpa.services: Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: Connection already associated with an application ID")
“Successfully bound” and “Failed to register” seem a bit contradictory to me, or is this expected?
The error
QDBusError("org.freedesktop.portal.Error.Failed")
started to happen after the last Qt's update in the Arch's repository. Somehow in kde the shortcuts work even with the registration error.
It is not clear to me if this is a Qt regression or a xdg api change that is not documented. I tried some changes to our code but so far I have no idea about how to fix this registration error.
started to happen after the last Qt's update in the Arch's repository
Do you know the package and version that caused this? I could try bisecting the exact commit.
Somehow in kde the shortcuts work even with the registration error.
So I guess the backend implementations, xdg-desktop-portal-kde and xdg-desktop-portal-gnome, must be handling things differently here.
I do not know which Qt package is related to the global shortcut management. But it was yesterday update that caused the registration error as far as I can remember. So from qt 6.10.0 to 6.10.1 something changed.
Now that I am looking at my system logs I see that several KDE apps are also showing the same qdbus error. Even programs like xdg-desktop-portal-kde and kwin_wayland are showing it. This Qt update definitely has something broken.
Meanwhile, I just wanted to comment that (as of yesterday's update) global shortcuts work again on GNOME despite the error. I don't have any idea what changed.