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

[Dawit A.]

On Thursday 08 October 2009 10:51:53 Michael Howell wrote:
> 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.

Okay... I can see the benefit of having convenient wrapper re-implementations 
that provide complete KDE integration for free ; so I will simplify these 
classes and leave them in there. My only desire was to make sure the essential 
KDE integration (KIO/CookieJar) can be done without having to inherit from 
these classes...

What I also wanted to discuss but forgot was putting the classes in kdewebkit 
under a namespace instead of simply replacing the Q with K. The namespace 
could be something like "KDEWebKit" or "KdeWebKit" so classes can be 
referenced as KdeWebKit::CookieJar instead of KNetworkCookieJar, 
KdeWebKit::WebPage instead of KWebPage for example... I also want to rename 
the files accordingly so they are easily distinguished. For example, 
kdewebpage.h, kdewebview.h kdewebpluginfactory.h, kdewebcookiejar.h etc.
Any input, objections ? If no objections which/what namespace should I use ?