Extended handling of magnet links

[Vladimir Perepechin]

Yep, magnet - it's an URI. It's has some information about resource, but
doesn't specify how to get it.

The problem is:
1) i'm web coder and i'm not good at c++.
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.

May be i shouldn't try to subclass uri handlers, but hardcode some logic
for magnet links directly...

On Sun, May 24, 2015 at 1:58 PM, Albert Astals Cid <aacid at kde.org> wrote:

> 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 <aacid at 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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150524/cc134979/attachment.htm>