For KCMs we get a relative entryPath() for our KService resulting in an invalid URL being created.
CCBUG: 397070
Details
Details
- Reviewers
hein dfaure - Group Reviewers
Plasma - Commits
- R120:cf7381d7fbff: [Service Runner] Look up relative entryPaths
- I can now search for "colors" and drag the colors KCM search result to the desktop and have a fully functioning shortcut
The KSycocaEntry::entryPath() docs say
The path can be absolute or relative.
The corresponding factory should know relative to what.
I'm not really a fan of adjusting all kinds of places where we use entryPath(), such as Kicker (as reported in the bug report), is there some better way? or at least a static resolve path function somewhere?
Diff Detail
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.
Comment Actions
I agree a more general fix would be nice, but at least Kicker has a whole bunch of downstreams itself ... I'd probably accept this, but I'd like to hear David's take.
| runners/services/servicerunner.cpp | ||
|---|---|---|
| 481 | Does it better to check that file exists? | |
| runners/services/servicerunner.cpp | ||
|---|---|---|
| 481 | QStandardPaths::locate already does that:
| |
Comment Actions
This relies on the fact that nowadays entryPath() is absolute for application desktop files (for a reason I forgot, must be related to the vfolder stuff), so relative means indeed relative to "kservices5".
BTW the reason why KService doesn't offer an absolute-file-path method is because one entry can be a merged view of local+global files (so the right way to read it is with KConfig, not QFile).
But yeah QMimeData doesn't support that :-)
I have no objection to this commit.