[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: QNetworkAccessManager and KDE's KIO
From:       Dario Freddi <drf54321 () gmail ! com>
Date:       2012-03-28 7:46:08
Message-ID: CAFFVnfPzHYB=6_=Fhc+iV3wZBnHT7-43v-e3vnWuvzWnYmfRwg () mail ! gmail ! com
[Download RAW message or body]

Il 23 marzo 2012 06:15, Weng Xuetian <wengxt@gmail.com> ha scritto:
> On Fri, Mar 23, 2012 at 6:53 AM, Albert Astals Cid <aacid@kde.org> wrote:
>> El Dimarts, 20 de mar=E7 de 2012, a les 12:26:05, Weng Xuetian va escriu=
re:
>>> 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 QWebVi=
ew.
>>>
>>> Any idea about how to solve this problem? Is simply keep a pointer to t=
he
>>> 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 t=
he
>> QNetworkAccessManager passed there.
>>
>> I'm not a huge expert in QNetworkAccessManager but it could work. So giv=
e 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 unsubscri=
be <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]