[WebKit-devel] KDE Webkit status update...

Dawit A. adawit at kde.org
Thu Oct 8 04:17:10 CEST 2009


On Tuesday 06 October 2009 15:49:12 Urs Wolfer wrote:
> On Tuesday 06 October 2009 07:27:32 Michael Howell wrote:
> > On Monday 05 October 2009 21:37:24 Dawit A. wrote:
> > > If you look at it from that point of view you when creating an API you
> > >  would realize that what is needed for QtWebKit/KDE integration is
> > >  re-implementation of the bulding block Qt classes such that all
> > >  applications/kparts, without exception, benefit equally. How do we do
> > > that ? Why we follow the precedence set by KIO::AccessMananger. For
> > > example, I am doing the same thing for the cookiejar integration right
> > > now. I am going to offer a wrapper class for inclusing in KIO or other
> > > appropriate location (e.g. wherever kdewebkit is going to go). Once
> > > that is done, all a developer has to do is simply create an instance of
> > > these classes and set them in the generic or own versions of the
> > > QWebView/QWebPage versions and viola KDE integration. Everything else
> > > to me is application/part or whatever specific and needs to be
> > > implement there.
> >
> > Make sense.
> 
> +1 from me as well. Makes sense to me.

Okay... I have changed webkitkde based on the concept I have outlined above.
However, because the changes I made are rather drastic, I want to discuss the 
details before I commit anything. So here is what i did:

#1. Factored out the KDE cookiejar integration code into own class. Since I do 
not know where this piece of code belongs, I have left it in kdewebkit for 
now. The new class is called KNetworkCookieJar.

#2. Deleted kdewebkit/kwebpage.* and folded all applicable code from it into 
part/webpage.*. This means WebPage in the part folder directly re-implements 
QWebPage.

#3. Deleted kdewebkit/kwebview.* and folded all applicable code from it into 
part/webview.*.  This means WebView in the part folder directly re-implements 
QWebView.

#4. Moved WebKitSettings from kdewebkit/settings to part/settings.

#5. Moved the searchbar code from kdewebkit to part/ui.

#6. Adjusted the cmake project files and installed header files accordingly and 
documented the classes in kdewebkit.

After these changes only two classes will be left in kdewebkit, 
KNetworkCookieJar and KWebPluginFactory. The first provides integration with 
KDE's cookiejar while the second provides KParts integration for objects 
embeded into HTML pages, e.g. <embed src="blah.mpg">. 

For demonstration purpose here is a quick example of how simple it is to do 
KDE integration:

QWebView *view = new QWebView(this);
KIO::AccessManager *manager = new KIO::AccessManager(view);

KNetworkCookieJar *cookieJar = new KNetWorkCookieJar;
manager->setCookieJar(cookieJar);
cookieJar->setParent(this);  // optional see setCookiejar documentation.

view->page()->setNetworkAccessManager(manager);
view->page()->setPluginFactory(new KWebPluginFactory(view));

Unless people have specific requirements like the webkitpart, there is no need 
to re-implement any of these classes. They can use the stock QtWebKit and 
simply set the readily provided re-implementations that provide KDE 
integration. For us less things to maintain, yay! Anyhow, let me know what you 
think...


More information about the WebKit-devel mailing list