<div dir="ltr">Yep, magnet - it's an URI. It's has some information about resource, but doesn't specify how to get it.<div><br></div><div>The problem is:</div><div>1) i'm web coder and i'm not good at c++.</div><div>2) I want to discuss this to implement a proper idea, may be someone have better ideas, or he knows why this shouldn't be done this way.</div><div><br></div><div>May be i shouldn't try to subclass uri handlers, but hardcode some logic for magnet links directly...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 24, 2015 at 1:58 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 Dilluns, 18 de maig de 2015, a les 22:52:27, Vladimir Perepechin va<br>
escriure:<br>
<span class="">> Yep.<br>
><br>
> The use case is following:<br>
> magnet links are used by absolutely different applications:<br>
> 1) Torrent (ktorrent)<br>
> 2) DC++ (eiskaltdcpp)<br>
> 3) eDonkey<br>
><br>
> Every application uses magnet links, but! Magnet links for every app are<br>
> different. ktorrent can't handle links for dc++.<br>
> The problem is that currently only one app at a time can handle ALL magnet<br>
> links.<br>
<br>
</span>So magnet:// is not really a protocol even if it is disguised as one?<br>
<br>
You should propose a patch in reviewboard and carry on with the discussion<br>
there i guess.<br>
<br>
Cheers,<br>
  Albert<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> So now when i clicking on a magnet link for dcpp - it opens in ktorrent.<br>
> And this is a problem.<br>
> If i'll change default app (kde doesn't allow me to do this, thanks got we<br>
> have xdg-mime) to dcpp-client - every torrent magnet link will be tried to<br>
> be opened in dcpp-client.<br>
> The solution for this is to use 3rd script that will handle links properly.<br>
> But i what a good native support for this in kde.<br>
><br>
> On Mon, May 18, 2015 at 9:42 PM, Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:<br>
> > El Dissabte, 16 de maig de 2015, a les 21:31:49, Vladimir Perepechin va<br>
> ><br>
> > escriure:<br>
> > > 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<br>
> ><br>
> > there<br>
> ><br>
> > > is nothing to do with kio_magnet.<br>
> ><br>
> > I tried running that forum page and this email and still i am not sure<br>
> > 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<br>
> > case?<br>
> ><br>
> > Cheers,<br>
> ><br>
> >   Albert<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<br>
> ><br>
> > how<br>
> ><br>
> > > it determines, but i've tried to add subclass for it ad it works like<br>
> > > 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<br>
> ><br>
> > and<br>
> ><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<br>
> ><br>
> > preferred<br>
> ><br>
> > > service for it. if no preferred service was found - looking for<br>
> > > 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<br>
> > > 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>