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

[Andrea Diamantini]

On Thursday 08 October 2009 04:17:10 Dawit A. wrote:
> 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...

This will be fantastic from rekonq pov.
Anyway, I'm not sure about sure about completely dropping kwebpage/kwebview 
classes.

To understand this choice I perhaps need to ask about future plans for 
kdewebkit.
What about for example, webactions KDE integration (dropped removing 
kwebpage)? 
Upcoming 4.6 web elements (and kwallet integration)?
shared browsing history?

Should every app implement these? no... :)
Are there plans about?

Regards,
-- 
Andrea Diamantini, adjam
GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F

rekonq project
WEB: http://rekonq.sourceforge.net
IRC: rekonq at freenode