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

[Dawit A.]

On Monday 05 October 2009 22:51:49 Michael Howell wrote:
> On Monday 05 October 2009 09:15:58 Dawit A. wrote:
> > On Sunday 04 October 2009 11:05:48 Urs Wolfer wrote:
> > > I just have found another issue we need to think about:
> > > kdewebkit/settings/webkitsettings.h is not a public header, but used by
> > > the part. This is a no-go. Either we need to cleanup this header and
> > > install it, or remove the direct ussage of this class. I prefer #2.
> >
> > Almost all of the WebSettings class deals with configuration that is
> >  specific to Konqueror and hence should be moved to webkitpart as well.
> > The two uses of WebKitSettings I personally added for determining whether
> > or not the cookiejar is enabled can easily be replaced with public
> > get/set member functions in KWebPage and the one that computes font sizes
> > can trivially be relocated to webkitpart where it actually belongs...
> 
> How are font defaults, JavaScript defaults, and such specific to Konqueror?
> KHTMLWidget gets those settings outside Konqueror. If your app needs them
> overridden (embedded WebKit using JavaScript), you can override them.

I actually meant khtmlpart not Konqueror. That is a mistake on my part. As 
such these configurations should be either part of the webkitpart or offered as 
a public API as demonstrated by the problem Urs mentioned above.

Let me throw back the same question at you. Why would a completely distinct 
and spearate web rendering engine need to read the settings and configuration 
of a completely different engine unless it wants to provide the same consistent 
look and feel when used in existing applications (which 99% of the time is 
Konqueror) ? Do all applications that use QtWebKit, but want to integrate with 
KDE technology want to use these khtml specific settings ? I somehow doubt that 
is the case... I just do not see why a browser like rekonq that uses QtWebKit, 
but want to provide KDE integration, want do that.

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.