kdewebkit moved to kdereview

[Dawit A.]

On Sunday 25 October 2009 23:48:27 Benjamin Meyer wrote:
> > Factory in the kdewebkit module that specifically does that...
> >
> >>> * KDE dialogs for javascript dialogs (alert, file picker, ..)
> >>
> >> The KDE File dialog should already be used starting with I believe
> >> KDE
> >> 4.3 when the static QFileDialog pointers were overloaded so anytime
> >> you call the static QFileDialog functions it will use the KDE File
> >> Dialog.  As for the alert dialog while it does use QMessageBox,
> >> QMessageBox should be using the KDE icon from the style which is the
> >> only thing I could see the KMessageBox adding.
> >>
> >> So what goes kdewebkit bring us that we don't either already have or
> >> will be getting with Qt4.6?
> >
> > See my response/example few threads back. But basically two out of
> > the three
> > public classes, KWebView and KWebPage, in kdewebkit are nothing more
> > than
> > simple convenience wrappers that provide complete KDE integration
> > out of the
> > box. That is you get the critical KIO, KCookieJar integration by
> > doing nothing
> > more than "KWebView *view = new KWebView (parent);".
> 
> The code example doesn't show why there needs to be a KWebView.

It does exactly what a convenience class is supposed to do...

#1. Calls setPage(new KWebPage(this)) in its ctor...
#2. Provides access to a couple of functions specific to our implementation of 
QNetworkAccessManager...
#3. Provides three signals related to mouse clicks...

> Looking at the example the majority of the code bloat was on the kde
> side and if all it does is set the network manager and plugin factory
> we should make it easy for people to still use their existing QtWebKit
> code and only inject two lines with something like:
>
> webPage->setNetworkAccessManager(new KNetworkAccessManager());
> webPage->setPluginFactory(new KWebPluginFactory());

With the exception of the missing CookieJar integration and the incorrect 
class names, there is absolutely nothing that stops you from doing just that! 
As I have already stated these are convenient classes to make the life of a 
KDE app developer easier!  Can you please clarify where exactly is the "code 
bloat" ??? 

> A while back I was looking at the code and it looked like the KWebView
> and KWebPage were tied together.  

And the keyword with that statement is a "while back". A lot of things have 
changed with the kdewebkit module in the past couple of months...

> It would be nice if I could stick a QWebPage on a KWebView or a KWebPage in
> a QWebView.  

Nothing stops you from doing that either! But you loose the KDE integration 
you get for free and will have to do the integration manually yourself!

> Application will want to overload these.  

Overload what ? Do you mean reimplement these classes ? If so, then u can do 
that just the same way you can their parent classes. Infact the webkitpart 
does that very thing itself, i.e. reimplements both KWebView and KWebPage...

> Also KWebPage should never require KWebView because applications will want
> to use KWebPage without KWebView or QWebView, but as a stand along object
> (many applications already do this).

It does not! You can see the code for yourself at
http://websvn.kde.org/trunk/kdereview/kdewebkit/