[WebKit-devel] KDE WebKit status update [Remix]

[Urs Wolfer]

On Saturday 10 October 2009 16:31:12 Dawit A. wrote:
> On Saturday 10 October 2009 09:26:51 Urs Wolfer wrote:
> > I have just looked into the changes and tested it. Looks very good to me;
> >  the only regression I have found is the searchbar: I cannot close it
> >  anymore (neither with esc nor with the close button). What do you think
> > is missing?
> 
> Oops... Fixed. It was missing the shortcut key assignment and the hide on
> close button click signal/slot connection

Thanks.
> 
> > IMHO it's almost ready to move the webkitkde/kdewebkit folder into
> > kdereview.
> 
> I am fine with that...
> 
> > After I think we should move the folder into kdelibs/kdewebkit.
> 
> I wonder if it is a good idea to put the experimental namespace on these
> wrappers until we get feedback from people that use the API as suggested
>  but not required by the new KDE library API policy ?
> 
> http://techbase.kde.org/Policies/New_KDE_Library_API_Policy

Yeah, probably an idea. The only downside is that we have to change every 
application if we change something in the experimental namespace (or when we 
move it out); but that's probably not a that hard thing... Though I wonder if 
it makes sense since we are not adding that much API over QtWebKit.

> > I'm not sure about the KNetworkCookieJar class, but IMHO it can stay in
> > kdewebkit since I'm not aware of any other ussage. Please correct me if
> > I'm wrong.
> 
> By that same reasoning, KIO::AccessManager should not be where it is now,
>  no ? That is the dilemma I have... If we put it in the wrong place and
>  release, we have to live with it for the life of KDE 4.  To me personally
> KNetworkCookieJar belongs the same place KIO::AccessManager went because
>  they are both KDE wrappers of Qt classes that come from the same Qt
>  module, QtNetwork. Just like their parent classes, their use is not
>  limited to QtWebKit or kdewebkit in this case. However, I am not entirely
>  sure what the KDE policy is on this issue, i.e. adding classes used by
>  only one module for now. Anyhow, if it ends up in KIO we have to change
>  the name as well. Perhaps to something like KIO::CookieJarAdapter to
>  clearly indicate its intended purpose, KDE integration only.

QNetworkAccessManager is also used by others than the webkit stuff in KDE [1]. 
I am not aware of a possible user of the Cookie stuff though. Are you?

Bye
urs

[1] http://lxr.kde.org/ident?i=QNetworkAccessManager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/webkit-devel/attachments/20091010/6fb41bd0/attachment.sig