For KCMs we get a relative entryPath() for our KService resulting in an invalid URL being created.
CCBUG: 397070
hein | |
dfaure |
Plasma |
For KCMs we get a relative entryPath() for our KService resulting in an invalid URL being created.
CCBUG: 397070
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?
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
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:
|
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.