El Dilluns, 18 de maig de 2015, a les 22:52:27, Vladimir Perepechin va escriure: > Yep. > > The use case is following: > magnet links are used by absolutely different applications: > 1) Torrent (ktorrent) > 2) DC++ (eiskaltdcpp) > 3) eDonkey > > Every application uses magnet links, but! Magnet links for every app are > different. ktorrent can't handle links for dc++. > The problem is that currently only one app at a time can handle ALL magnet > links.
So magnet:// is not really a protocol even if it is disguised as one? You should propose a patch in reviewboard and carry on with the discussion there i guess. Cheers, Albert > > So now when i clicking on a magnet link for dcpp - it opens in ktorrent. > And this is a problem. > 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. > The solution for this is to use 3rd script that will handle links properly. > But i what a good native support for this in kde. > > On Mon, May 18, 2015 at 9:42 PM, Albert Astals Cid <aa...@kde.org> wrote: > > El Dissabte, 16 de maig de 2015, a les 21:31:49, Vladimir Perepechin va > > > > escriure: > > > 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. > > > > I tried running that forum page and this email and still i am not sure > > what > > you want to do, so let me do a quick question. > > > > Do you want to open magnet:/ urls with different apps? What's the use > > case? > > > > Cheers, > > > > Albert > > > > > 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 > > > mime-type. > > > > > > 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: > > > http://pastebin.com/4crCJRLZ > > > > > > 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?
