| Summary: | Does not respect the local modifications of the .desktop file | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kglobalaccel | Reporter: | Juan Simón <decedion> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | kde, nate, nicolas.fella, plasma-bugs-null, zawertun |
| Priority: | NOR | ||
| Version First Reported In: | 5.77.0 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Juan Simón
2020-12-17 10:02:28 UTC
Seems like an issue in kglobalaccel itself. I think I understand the problem. The shortcut information is read from /usr/share/kglobalaccel/org.kde.spectacle.desktop, which is a symlink to /usr/share/applications/org.kde.spectacle.desktop Therefore adding/changing .local/share/applications/org.kde.spectacle has no effect on what is read from /usr/share/kglobalaccel/org.kde.spectacle.desktop The rationale of /usr/share/kglobalaccel/ was that we don't need to parse every desktop file on startup. Maybe we can kill it and find some other options such as having kded/kservice track that somewhere when it rebuilds other service related caches. By using KService we would use the already existing ksycoca database, no? I threw a KApplicationTrader::query into the code and measured: The query contributes 5% cycles of the first second of kglobalacceld running. |