Extended handling of magnet links

Vladimir Perepechin vovochka13 at gmail.com
Sat May 16 12:31:49 BST 2015

Hi everyone :)

I was thinking about implementing my idea
https://forum.kde.org/viewtopic.php?f=83&t=126352 .
While digging sources i've understand that my idea was incorrect, and there
is nothing to do with kio_magnet.

My second thought was to store any additional info in mimeinfo while
detecting it from url, but after more digging i came to mime subclasses.
In fact,  i understand that x-scheme-handler is very simple in the way how
it determines, but i've tried to add subclass for it ad it works like for
any other mime-types.

The only problem is: KRun dosn't looking into mime-database when working
with x-scheme-handlers. So i came here with  the following proposition.

Extend schemeHandler function of KRun.
1) we are looking for all mime-types that statrs with x-scheme-handler and
has base handler in a parentMimeTypes.
2)If we found such mime-type - check url against globPatterns of found

3) So, if we found subclassed mime-type for our url - try to find preferred
service for it. if no preferred service was found - looking for preferred
service for our base mime-type (as it was done before)

So, it will be something like this: http://pastebin.com/Wgni5iBP
I'm not a c++ coder, so this isn't most optimized solution, but it shows
the idea.

Next step:
Just ship xml with magnet url subclass with ktorrent:

And add x-scheme-handler/x-magnet-btih to ktorrent.desktop MimeType list.

Doing similar with other magnet handlers (like dcpp) will allow us to
separate magnet handling by appropriate application.

So, what do u think? Is this idea wrong? Any other ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150516/ba0eb4b3/attachment.htm>

More information about the kde-core-devel mailing list