kdewebkit moved to kdereview

[Benjamin Meyer]

> 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.   
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());

A while back I was looking at the code and it looked like the KWebView  
and KWebPage were tied together.  It would be nice if I could stick a  
QWebPage on a KWebView or a KWebPage in a QWebView.  Application will  
want to overload these.  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).

-Benjamin Meyer