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

[Michael Howell]

On Wednesday 07 October 2009 19: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...
> _______________________________________________
> WebKit-devel mailing list
> WebKit-devel at kde.org
> https://mail.kde.org/mailman/listinfo/webkit-devel
> 
I disagree about completely dropping KWebPage/View. If we keep them, we could 
add more elements of KDE integration and apps will get it for free. (e.g. 
wallet integration)

Of course, by factoring out the CookieJar and friends, KWebPage/View are made 
to be very simple classes.

-- 
Please don't send HTML-only mail (if you like, you can use multipart). If you 
forward messages, please clean off the garbage. Thanks! 
Michael Howell 
mhowell123 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/webkit-devel/attachments/20091008/a64391f6/attachment.sig