Re: Extended handling of magnet links
Yep, it must be a cool thing, but i don't think that it is a good idea. 1) All this p2p stuff has a listening port. (requires configuration, upnp and so on) 2) Some protocols requires pre-configuration. For ei dc++ requires hub and unique nickname. 3) In p2p world it's good to sid what u've downloaded. How that should be implemented with kio? 4) Several different protocols in one thing - re implementing mldonkey in kio - i don't think it'a good idea. On Mon, May 25, 2015 at 1:00 AM, Aleix Pol aleix...@kde.org wrote: On Sat, May 16, 2015 at 1:31 PM, Vladimir Perepechin vovochk...@gmail.com wrote: Hi everyone :) I was thinking about implementing my idea https://forum.kde.org/viewtopic.php?f=83t=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 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? Maybe you'd like to work on the kio-magnet? I think it could be a really cool thing to have. Aleix
Re: Extended handling of magnet links
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 aa...@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 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=83t=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?
Re: Extended handling of magnet links
On Sat, May 16, 2015 at 1:31 PM, Vladimir Perepechin vovochk...@gmail.com wrote: Hi everyone :) I was thinking about implementing my idea https://forum.kde.org/viewtopic.php?f=83t=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 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? Maybe you'd like to work on the kio-magnet? I think it could be a really cool thing to have. Aleix
Re: Extended handling of magnet links
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=83t=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?
Re: Extended handling of magnet links
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 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=83t=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?
Re: Extended handling of magnet links
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=83t=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?
