From kde-devel Wed Mar 28 09:26:40 2012 From: Dario Freddi Date: Wed, 28 Mar 2012 09:26:40 +0000 To: kde-devel Subject: Re: QNetworkAccessManager and KDE's KIO Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=133292689801700 Il 28 marzo 2012 10:22, Weng Xuetian ha scritto: > On Wed, Mar 28, 2012 at 3:46 PM, Dario Freddi wrote: >> Il 23 marzo 2012 06:15, Weng Xuetian ha scritto: >>> On Fri, Mar 23, 2012 at 6:53 AM, Albert Astals Cid wrot= e: >>>> El Dimarts, 20 de mar=E7 de 2012, a les 12:26:05, Weng Xuetian va escr= iure: >>>>> Hi, >>>> >>>> Hi >>>> >>>>> I'm currently implementing a library that require network access, and= I need >>>>> some custom url such as "myapp://" to do oauth callback, so I create a >>>>> class inherits QNetworkAccessManager. >>>>> >>>>> But I found if anyone want to KDE's KIO::Integration::AccessManager to >>>>> replace the NetworkAccessManager in order to use KDE proxy setting an= d KIO, >>>>> there will be some problem. I don't want this library hardly depends = on >>>>> KDE, but I also hope it can integrate with KDE well. >>>>> >>>>> I read attica's code but seems it use a custom interface, which is not >>>>> fesible here since I need to set the NetworkAccessManager to the QWeb= View. >>>>> >>>>> Any idea about how to solve this problem? Is simply keep a pointer to= the >>>>> old networkmanager and redirect createRequest to it enough? >>>> >>>> I think you could make your QNetworkAccessManager have a >>>> setNonMyAppAccessManager() and then all the calls that happen to your >>>> MyAppNetworkAccessManager that are not myapp:// you redirected them to= the >>>> QNetworkAccessManager passed there. >>>> >>>> I'm not a huge expert in QNetworkAccessManager but it could work. So g= ive it a >>>> try :-) >>>> >>>> Cheers, >>>> =A0Albert >>>> >>>>> >>> I don't think so... since all other call to QNetworkAccessManager will = be wrong. >> >> The solution Albert proposed is actually correct instead, and already >> used by several other applications/libraries. Obviously, you would >> have to construct a default QNetworkAccessManager if none is supplied >> from the outside. This also would make your whole library >> implementation more flexible also outside the KDE realm. >> >>> >>> Anyway.. I try a different solution, create two plugin, which have the >>> similar logic at the createRequest, though some of code are duplicate, >>> but it's small and will works. >>> >>>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubsc= ribe << >> >>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscr= ibe << > > The problem is, I need to override the default createRequest, even for > the KIO::AccessManager, in order to process OAuth custom callback. > > Here is my approach: https://github.com/csslayer/qcloud/tree/master/netwo= rk/kde > > This is actually a plugin and can create custom networkaccessmanager > object , which derive from KIO::AccessManager. Now it's clear, thanks. Then indeed what you did seems to me the most reasonable approach, but I see another potential problem. AFAIK (probably other people more knowledgeable than me about the subject could expand) one of the main points of KIO::AM is to actually reimplement this function by providing a different reply, but you are overriding it by feeding it a QCloud reply. I have the feeling your QCloud reply might need some additional modifications to follow, for example, proxy settings enforced by KIO::AM. But again, please double check this information as this: 1. depends on what you are doing inside your reply, since I didn't have time to look through all of the code 2. Is still something I'd like to have confirmed by somebody who knows more than me about the topic. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib= e <<