El Divendres, 23 de març de 2012, a les 13:15:07, Weng Xuetian va escriure: > On Fri, Mar 23, 2012 at 6:53 AM, Albert Astals Cid <aa...@kde.org> wrote: > > El Dimarts, 20 de març de 2012, a les 12:26:05, Weng Xuetian va escriure: > >> 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 and > >> 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 > >> QWebView. > >> > >> 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 give > > it a try :-) > > > > Cheers, > > Albert > > I don't think so... since all other call to QNetworkAccessManager will be > wrong.
Which other calls? Albert > > 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 unsubscribe > >> << >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
