Trying to make a shortcut to my shell script I've created a desktop file in .local/share/aplications/. Then, I've added the app in the global shortcuts with systemsettings5. STEPS TO REPRODUCE 1. Create the file ~/.local/share/applications/vlc-bébé.desktop [Desktop Entry] Encoding=UTF-8 Name=VLC bebe Comment=VLC avec la playlist bebe Exec=vlc-bebe.sh Icon=vlc Type=Application 2. Open systemsettings5, global shortcuts, add this "app". 3. Add shortcut "ctrl+alt+Q", quit systemsettings. OBSERVED RESULT On next start of systemsettings5, open "Shortcuts" (global shortcuts). This fails with: Failed to contact the KDE global shortcuts daemon Message: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Error: org.freedesktop.DBus.Error.NoReply SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro kglobalaccel 5.57.0-2 (available in About System) KDE Plasma Version: 5.57 KDE Frameworks Version: Qt Version: 5.12.3 ADDITIONAL INFORMATION A. In journalctl -f I get: kglobalaccel5[28685]: QDBusObjectPath: invalid path "/component/vlc_bébé_desktop" kglobalaccel5[28685]: QDBusConnection: error: could not send reply message to service "": Marshalling failed: Invalid object path passed in arguments B. I guess the issue is because of the UTF8 characters in the filename or file content. C. As a result, I can't access the global shortcuts panel in systemsettings5. How can I remove this offending entry? I've tried to edit ~/.config/kglobalaccelrc but the offending group "vlc-bébé.desktop" reappears on next login. Where is this data stored?
Desktop filenames cannot contain international characters. They are transmitted via D-Bus and need to be ASCII. Of course the Name= field can contain any characters.
Thanks for your feedback. I'm reopening because : 1. It's not possible to access kglobalaccel via systemsettings5 anymore and I've found no way to recover from this issue. 2. Trying to reset to the defaults makes systemsettings5 to crash. 3. There should be a warning or error at creation time when adding the desktop app file. Once the destop app file is added via systemsettings5 it's too late. The kde configuration system is bugging and crashing after the destop app was added.
Oddly, KGlobalAccel does appear to have some code in its DBus component handler to try to clean up paths to conform to DBus requirements. See src/runtime/component.cpp:203: QDBusObjectPath Component::dbusPath() const { QString dbusPath = _uniqueName; // Clean up for dbus usage: any non-alphanumeric char should be turned into '_' const int len = dbusPath.length(); for ( int i = 0; i < len; ++i ) { if ( !dbusPath[i].isLetterOrNumber() ) dbusPath[i] = QLatin1Char('_'); } // QDBusObjectPath could be a little bit easier to handle :-) return QDBusObjectPath( _registry->dbusPath().path() + "component/" + dbusPath); } The problem seems to be the ".isLetterOrNumber" check, which doesn't actually strip non-ASCII characters. Since every character in "bébé" is a Unicode letter, no translation happens here. Added a check that the QChar returned by dbusPath[i] is actually a latin-1 characters (e.g. with QChar::toLatin1) would seem to be necessary.
"é" is a Latin-1 character, but not ASCII. It needs an additional ch.unicode() < 0x7F check.
> As a result, I can't access the global shortcuts panel in systemsettings5. How can I remove this offending entry? I've tried to edit ~/.config/kglobalaccelrc but the offending group "vlc-bébé.desktop" reappears on next login. Where is this data stored? I'm having this same problem, do you have a solution or workaround to solve this?? I created a shortcut with an entry named "Selecionar área do print.desktop" and now I'm getting: `DBusObjectPath: invalid path "/component/Selecionar_área_do_print_desktop"`
(In reply to Christoph Feck from comment #4) > "é" is a Latin-1 character, but not ASCII. It needs an additional > ch.unicode() < 0x7F check. Having just the same problem in Kglobalaccel after adding a shortcut to a desktop file with chinese characters. Adding this additional check may solve it,but how can this be done?
(In reply to crc from comment #6) > (In reply to Christoph Feck from comment #4) > > "é" is a Latin-1 character, but not ASCII. It needs an additional > > ch.unicode() < 0x7F check. > > Having just the same problem in Kglobalaccel after adding a shortcut to a > desktop file with chinese characters. Adding this additional check may solve > it,but how can this be done? I finally solved the problem by adding the additonal check to the soucecode of Kglobalaccel cloning from https://anongit.kde.org/kglobalaccel.git and compiling it in my system, then created a soft link from the compiled Kglobalaccel5 file to /usr/bin, it just worked fine. So this is certainly proved to be at least a temporary solution for the problem, many thanks!!!
(In reply to crc from comment #7) > (In reply to crc from comment #6) > > (In reply to Christoph Feck from comment #4) > > > "é" is a Latin-1 character, but not ASCII. It needs an additional > > > ch.unicode() < 0x7F check. > > > > Having just the same problem in Kglobalaccel after adding a shortcut to a > > desktop file with chinese characters. Adding this additional check may solve > > it,but how can this be done? > > I finally solved the problem by adding the additonal check to the soucecode > of Kglobalaccel cloning from https://anongit.kde.org/kglobalaccel.git and > compiling it in my system, then created a soft link from the compiled > Kglobalaccel5 file to /usr/bin, it just worked fine. So this is certainly > proved to be at least a temporary solution for the problem, many thanks!!! Could you send a snippet with what exactly you added?
(In reply to José Renan from comment #8) > (In reply to crc from comment #7) > > (In reply to crc from comment #6) > > > (In reply to Christoph Feck from comment #4) > > > > "é" is a Latin-1 character, but not ASCII. It needs an additional > > > > ch.unicode() < 0x7F check. > > > > > > Having just the same problem in Kglobalaccel after adding a shortcut to a > > > desktop file with chinese characters. Adding this additional check may solve > > > it,but how can this be done? > > > > I finally solved the problem by adding the additonal check to the soucecode > > of Kglobalaccel cloning from https://anongit.kde.org/kglobalaccel.git and > > compiling it in my system, then created a soft link from the compiled > > Kglobalaccel5 file to /usr/bin, it just worked fine. So this is certainly > > proved to be at least a temporary solution for the problem, many thanks!!! > > Could you send a snippet with what exactly you added? Sorry for replying late. I just modified Kglobalaccel source code in src/runtime/component.cpp following your and Michael Pyne's suggestions. The modification of component.cpp:203 is as follows: QDBusObjectPath Component::dbusPath() const { QString dbusPath = _uniqueName; const int len = dbusPath.length(); for ( int i = 0; i < len; ++i ) { if ( !dbusPath[i].isLetterOrNumber() || dbusPath[i].unicode() >= 0x7F) dbusPath[i] = QLatin1Char('_'); } return QDBusObjectPath( _registry->dbusPath().path() + "component/" + dbusPath); } I just add "dbusPath[i].unicode() >= 0x7F" check after the original ".isLetterOrNumber()" check, which will translate all international characters to "_". I have to admit that I'm no program developer and only learned some basic c++ during college time, so I'm not quit sure whether this adding is all correct. But after this modification the compile progress went smoothly and the complied Kglobalaccel5 run all fine on my Manjaro system, the bug never appeared again, so I think this can prove that the check adding just works.
Git commit f784038a7aa9be63927cef0d526b708bd6d21af0 by Nate Graham, on behalf of José Renan Silva Luciano. Committed on 26/05/2020 at 21:39. Pushed by ngraham into branch 'master'. Fix bug with components containing special characters FIXED-IN: 5.71 M +2 -1 src/runtime/component.cpp https://invent.kde.org/frameworks/kglobalaccel/commit/f784038a7aa9be63927cef0d526b708bd6d21af0
Hi there! I reopend this bug report
Hi there! I reopened this bug report because the very same problem reappeared since version 5.98. I've noticed that the code in Kglobalaccel's dBus components handler to transform all non-ascii characters in a path to ''_" has been changed to use "replace" function in C++, probably brought the bug back. For example, in my system a desktop file named "网易云音乐.desktop" (the file has long been deleted and I don't know why the path remains there) was wrongly transformed to "网___乐_desktop", causing "invalid path" error report in dbus, and made it impossible to access kglobalaccel via systemsettings5 anymore. I tried to restore the old script that once saved the problem (see comment 9) in kglobalaccel's source code and recompile it, then the bug was all gone. So I think the current code of kglobalaccel may need rechecking.
Good catch. Since you've already done some investigation, would you be interested in submitting a merge request to fix it?
(In reply to Nate Graham from comment #13) > Good catch. Since you've already done some investigation, would you be > interested in submitting a merge request to fix it? Many thanks for your appreciate! But unfortunately I'm not a professional developer, so I don't know how to correctly submit a merge request. Besides, the original code solving the problem seems primal, even a bit ugly now. So I suggest the current code changing may have its own reason, and simply restore the old one,which is the only workaround I found, may not be a good choice for a long term solution.
It can't hurt to try. :) You can solicit comments from experienced developers in the merge request. They are *much* more likely to do so there than to notice this bug report. https://community.kde.org/Infrastructure/GitLab#Submitting_a_Merge_Request
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/76