[WebKit-devel] GSoC proposals

[Dawit A]

Hi Allan,

First thanks for asking for ideas from us, which actually is mostly me and 
occasionally Urs... 

On Thursday 25 February 2010 07:50:01 Allan Sandfeld Jensen wrote:
> Hello WebKitPart'ers
> 
> There's  a few konqueror proposals on the GSoC page, can you please
> brainstorm and see if there is something you would like to add?

Perhaps the TODO file in extragear/base/kwebkitpart/ 

http://websvn.kde.org/trunk/extragear/base/kwebkitpart/TODO?revision=1095914&view=markup

might serve as a starting point... Some of the items listed in that file might 
be a great fit for a possible GSoC project. Specifically modifying all the 
"essential" konq-plugins, such as ad-block, searchbar and kget to support 
kwebkitpart would be of great help. There is already support for these 
plugins, but it is not completely 100%.

> The project about easier engine-switching is very small and I imagine it
> will combine well with some more porting or integration work in
> webkitpart, but I am unsure what people here are working on currently, so
> I want to pass the suggestions by you.

The "easier" engine switcher work is actually huge and a lot more work than 
people think. For example, the issue with the user agent string. Every time a 
user enters a request in its location bar, Konqueror directly uses KIO to 
determine the resource type (mime-type) so that is can embed the proper part 
to handle the request. Unfortunately, when the request is a web page, the user 
agent string that will be sent by default is the one returned by 
KProtocolManager::userAgentForUrl(...) which defaults to... KHTML's string. As 
such, implementing this feature correctly will require more work than just a 
few lines of code to switch rendering engines easily.


> So correct me if I am wrong, but are you still missing a few features from
> KHTML:
>  * Incremental search dialog
>  * Form completion dialog
>  * Smooth scrolling
>  * Java
>  * AdBlocK

Let me address each one of these...

** Java support : must be addressed at QtWebKit level. There is no way to 
address that anywhere else without a huge and rather ugly hack! And that is 
even if it is possible in the first place...

** Form completion: this too must be addressed at the QtWebKit level. 
Otherwise, this is going to be yet another ugly hack that will have to use 
javascript much like some websites do, e.g. google.com, in order to provide 
this functionality. 

Please note that the form completion support I am speaking of here is 
completely different from KWallet support, i.e. saving login information and 
automatically filling it when you visit that page. That feature is already 
available for any application that uses kdewebkit. Hence, currently the recent 
version of reKonq, khtml and kwebkitpart all share the information saved from 
one application in another one.

** Smooth scrolling: not exactly sure what you mean by this... Is the fancy 
automated scrolling one gets through by pressing Shift+Up/Down arrows ? If so, 
that too should be very easy to implement and something that should be 
classified as junior job instead of 

** Incremental search: If this is the CTRL+F stuff, then it has been 
completely implemented already. There are minor bugs, but they all have to be 
addressed upstream as well.

** Ad Block: There is already a simple support for blocking urls that uses 
exactly the same thing KHTMLPart uses. But as usual since most of the konq-
plugins were designed before the existence of KWebKitPart, this plugin like a 
few others, requires modification to work as well in KWebKitPart as it does in 
KHTMLPart. 

However, it should be much simpler to implement this for kwebkitpart since it 
automatically exposes its internal rendering engine through the view() 
function which returns a QWebView object. In fact, the custom implementation 
of KIO::Intergation::AccessManager class should be moved out from kwebkitpart 
to where ever the adblock plug-in is. 

Anyhow, for anyone interested in knowing the current state of kdewebkit, the 
KDE integration wrapper for QtWebKit used by all webkit based browsers or 
kparts, then they can look at the ISSUES file that was added few days ago:

http://websvn.kde.org/trunk/KDE/kdelibs/kdewebkit/ISSUES?revision=1095052&view=markup