[WebKit-devel] RFC: API for KWebWallet...

[David Faure]

On Friday 06 November 2009, Michael Howell wrote:
> On Thursday 05 November 2009 15:59:28 Dawit A. wrote:
> > Hi all,
> >
> > Attached is the first take for a QtWebKit/KWallet integration class,
> > KWebWallet, I am currently working on. The functions present there are
> >  mostly documented, but some bits and pieces are current missing. Note
> > that there is no implementation of this class yet! This is only my
> > attempt to get the API worked out first...
> >
> > I have purposefully kept the API I created as simple as possible. You
> > call saveFormData, most likely from acceptNavigationRequest when the
> >  NavigationType is NavigationTypeFormResubmitted, to save the form data
> > and to restore it you would probably connect the
> > restoreFrameStateRequested QWebPage signal to the restoreFormData slot
> > from this class.
> >
> > However, the above is only my approach and I need feedback a what people
> >  want to get from this API...
> 
> Why not, instead of using a signal on the KWebWallet object, return a KJob
>  or a QFuture from the saveFormData, like, for example,
>  QNetworkAccessManager (I know, it actually returns a QReply...) and KIO
>  do.

I don't understand how this can be implemented with a QFuture (which seems to 
be only for threads, and only implementable by Qt itself?).

>  In fact, a QFuture would even eliminate the need for synchronous job
>  support, since QFuture takes care of that.

(KJob does that too, with its exec() method but that one is dangerous in GUI 
apps, since timers and sockets can lead to re-entrancy).
But then again, any solution that involves "waiting on a signal to be fired" is 
going to have the exact same problem. So let's forget about synchronous here, 
IMHO.

I don't see another solution than a signal. After all it's the perfect model 
for an async operation. You can encapsulate the operation in a job or reply 
object (that's indeed better for modularity, to avoid N slots checking if the 
emitter is the one they care about), but that job or reply will also have to 
emit a signal anyway; anyway in this case each part would have its own 
KWebWallet instance anyway, so it doesn't seem really necessary.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).