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

Dawit A. adawit at kde.org
Sat Oct 10 06:18:35 CEST 2009


I have have committed the big changes to kdewebkit that were discussed in a 
previous thread here:

http://mail.kde.org/pipermail/webkit-devel/2009-October/000256.html

I am starting a new thread for the aftermath to keep the before and after 
discussions separate.

The changes were commited in one shot to make it easy to back out if the need 
arises for doing that. Other than that there are no new features or bug fixes 
that were included in this commit. Only the discussed code refactoring and 
reorganization. Anyhow here is a summary of the modifications:

#1. Moved search bar code to part/ui and clean up the class. I have also 
removed the fancy animation that was done using QTimeLine from this class for 
now. It can be put back in if there really is a need to do such thing for this 
kind of widgets. The F3/Shift+F3 button should now work correctly. Also when 
no match is found the line edit shows the same no match found color as khtml.

#2. Moved all code that has to do with WebKitSettings to part and moved the 
settings folder itself to the part module. The reason for this has already 
been discussed above ; so I will not repeat it.

#3. Changed KWebView/KWebPage to be simple KDEified wrappers for their Qt 
counter parts. They are now convenience classes that provide full KDE 
integration, but are not a requirement for integrating QtWebKit based 
applications with KDE. See the klauncher test application to see an example of 
that.

#4. Factored out the re-implementation of QNetworkCookieJar into its own 
class, KNetworkCookieJar. Note that I have not added the header file for this 
class to the the includes folder in kdewebkit because I am currently unsure 
where it should end up. kdewebkit ? kio/kio like KIO::AccessManager because it 
too comes from Qt's Network module ? Dunno... But it does not make sense to 
put this class under kdewebkit since its use is not limited to QtWebKit.

#5. Documented as much of these classes as possible, but I believe a more 
detailed documentation with examples is needed for KWebView and KWebPage.

None of these changes should break existing functionality and if it does 
please report it. Suggestions/feedbacks are all welcome, specially about item 
#4 and where to put that new class...


More information about the WebKit-devel mailing list