<div dir="ltr">Yep.<div><br></div><div>The use case is following:</div><div>magnet links are used by absolutely different applications:</div><div>1) Torrent (ktorrent)</div><div>2) DC++ (eiskaltdcpp)</div><div>3) eDonkey</div><div><br></div><div>Every application uses magnet links, but! Magnet links for every app are different. ktorrent can't handle links for dc++.</div><div>The problem is that currently only one app at a time can handle ALL magnet links.</div><div><br></div><div>So now when i clicking on a magnet link for dcpp - it opens in ktorrent. And this is a problem.</div><div>If i'll change default app (kde doesn't allow me to do this, thanks got we have xdg-mime) to dcpp-client - every torrent magnet link will be tried to be opened in dcpp-client.</div><div>The solution for this is to use 3rd script that will handle links properly.</div><div>But i what a good native support for this in kde.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 18, 2015 at 9:42 PM, Albert Astals Cid <span dir="ltr"><<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">El Dissabte, 16 de maig de 2015, a les 21:31:49, Vladimir Perepechin va<br>
escriure:<br>
<span class="">> Hi everyone :)<br>
><br>
> I was thinking about implementing my idea<br>
> <a href="https://forum.kde.org/viewtopic.php?f=83&t=126352" target="_blank">https://forum.kde.org/viewtopic.php?f=83&t=126352</a> .<br>
> While digging sources i've understand that my idea was incorrect, and there<br>
> is nothing to do with kio_magnet.<br>
<br>
</span>I tried running that forum page and this email and still i am not sure what<br>
you want to do, so let me do a quick question.<br>
<br>
Do you want to open magnet:/ urls with different apps? What's the use case?<br>
<br>
Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> My second thought was to store any additional info in mimeinfo while<br>
> detecting it from url, but after more digging i came to mime subclasses.<br>
> In fact,  i understand that x-scheme-handler is very simple in the way how<br>
> it determines, but i've tried to add subclass for it ad it works like for<br>
> any other mime-types.<br>
><br>
> The only problem is: KRun dosn't looking into mime-database when working<br>
> with x-scheme-handlers. So i came here with  the following proposition.<br>
><br>
> Extend schemeHandler function of KRun.<br>
> 1) we are looking for all mime-types that statrs with x-scheme-handler and<br>
> has base handler in a parentMimeTypes.<br>
> 2)If we found such mime-type - check url against globPatterns of found<br>
> mime-type.<br>
><br>
> 3) So, if we found subclassed mime-type for our url - try to find preferred<br>
> service for it. if no preferred service was found - looking for preferred<br>
> service for our base mime-type (as it was done before)<br>
><br>
> So, it will be something like this: <a href="http://pastebin.com/Wgni5iBP" target="_blank">http://pastebin.com/Wgni5iBP</a><br>
> I'm not a c++ coder, so this isn't most optimized solution, but it shows<br>
> the idea.<br>
><br>
><br>
> Next step:<br>
> Just ship xml with magnet url subclass with ktorrent:<br>
> <a href="http://pastebin.com/4crCJRLZ" target="_blank">http://pastebin.com/4crCJRLZ</a><br>
><br>
> And add x-scheme-handler/x-magnet-btih to ktorrent.desktop MimeType list.<br>
><br>
> Doing similar with other magnet handlers (like dcpp) will allow us to<br>
> separate magnet handling by appropriate application.<br>
><br>
><br>
> So, what do u think? Is this idea wrong? Any other ideas?<br>
<br>
</div></div></blockquote></div><br></div>