When an application got renamed by flatpak-builder without knowing it, it will still send its original value as desktop-entry breaking the mapping and settings.
Details
- Reviewers
sitter davidedmundson - Group Reviewers
Plasma - Commits
- R120:9258ef586324: [Notifications] Resolve X-Flatpak-RenamedFrom
Telegram sent telegramdesktop as desktop-entry, now resolves to the actual desktop file org.telegram.desktop
This likely needs an addition to the application.desktop KService definition and there's also a bug in the service trader/parser not handling desktop file lists properly (they are separted by semi-colon ; and have a trailing one, vs KConfig which is just a simple comma ,)
Diff Detail
- Repository
- R120 Plasma Workspace
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
libnotificationmanager/notification_p.h | ||
---|---|---|
53 | A bit off topic: is there any point for making this method static? You could get away with making serviceForDesktopEntry function static in the cpp file. |
if (!service) { const QString desktopId = desktopEntry + QLatin1String(".desktop"); const auto services = KServiceTypeTrader::self()->query(QStringLiteral("Application"), QStringLiteral("exist Exec and exist [X-Flatpak-RenamedFrom]")); for (auto it = services.constBegin(); it != services.constEnd() && !service; ++it) { const QVariant renamedFrom = (*it)->property(QStringLiteral("X-Flatpak-RenamedFrom"), QVariant::String); const auto names = renamedFrom.toString().split(QChar(';')); for (const QString &name : names) { if (name == desktopId) { service = *it; break; } } } }
Please try with this.
KService doesn't know how to properly deserialize X-* stringlists because we have some desktop files which still use comma lists and others which use semicolon lists. Because of this a trader query for semicolon separated lists won't work unless KService::property() gets special hardcoded handling to read the list as an XDG type rather than a KConfig type. From a speed POV the above code and a complete query are just about the same as a query too would simply go into property() to read the property and then check against constraints in the query.
The obvious alternative of course is to extend KService. IMHO putting X-* keys into KService is fairly awkward though. Another option would be to introduce ::xdgProperty() and then extend the query language to specify a type expectation (e.g. ('%1' in XDG[X-Flatpak-RenamedFrom]).