dfaure accepted this revision.
dfaure added inline comments.
This revision is now accepted and ready to land.
INLINE COMMENTS
> meven wrote in desktopexecparser.cpp:213
> > Can you call mimeTypes() instead of serviceTypes() here? I'm trying to
> > slowly split the two notions, after it all got mixed up long ago.
>
> No in fact, "x-scheme-handler/<protocol>" are not included in
> KService::mimeTypes() :
>
> > if (db.mimeTypeForName(sv).isValid()) { // keep only mimetypes, filter
> > out servicetypes
OK, I see.
> krun.cpp:962
> + if (exec.isEmpty()) {
> + // the scheme has no kio protocol associated
> + // use default mimetype opener for file
That is not true. isHelperProtocol returns true so there *is* a kio .protocol
file.
Just no kioslave behind it.
A helper protocol is like vnc.protocol which sends vnc urls to the `krdc`
program.
So it says exec=krdc '%u'.
A helper protocol with an empty exec line is weird, but I see a few like
mms.protocol (https://bugs.kde.org/show_bug.cgi?id=84664 has some context).
A helper protocol with an empty exec line *and* a default mimetype... well
there's one: rtsp.protocol which says defaultMimetype=audio/x-pn-realaudio.
Well at least I see the point of that: it'll launch the app associated with
that mimetype, for any rtsp://url.
OK, scheme-handler replaces most of these uses. I think we should just
deprecate "helper protocols" (which either hardcode an exec line or abuse
mimetypes) and move it all to the scheme-handler mechanism.
That's unrelated to your change so let's do that separately, of course.
For now, this comment makes no sense, you can just remove this line (962) and
push.
REPOSITORY
R241 KIO
BRANCH
arcpatch-D26557
REVISION DETAIL
https://phabricator.kde.org/D26557
To: meven, ervin, ngraham, #frameworks, dfaure
Cc: dfaure, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
