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

[Dawit A.]

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 

> 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

> 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.