[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