D26557: Allow to handle apps with Terminal=True in their desktop file, handle their associated mimetype properly

[David Faure]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200113/36ce02f2/attachment.html>