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

[Dawit A.]

On Saturday 03 October 2009 01:26:42 Michael Howell wrote:
> On Friday 02 October 2009 16:54:13 Dawit A. wrote:
> > One more additional issue which I am most definitely going to fix is
> >  SearchBar being exposed through a public QWidget* searchBar() accessor
> >  function. This is complete no no to me especially since the SearchBar
> > API itself is private! Anyhow, it is simple enough to address this matter
> > through few slots and perhaps signals...
> 
> You mean by placing the search bar widget inside the QWebView? Unless
> something has changed, that's impossible. The QWebPage paints directly to
>  the QWebView, making it impossible to place anything else into it. As a
>  result, you have to contain the search bar and the QWebView in the same
>  parent widget, which is what the QWidget* searchBar() thing is for.

Obviously, it is useless to attempt and add the widget to QWebView since we 
have no control over how that widget gets rendered. However, we can do one of 
two things without having to expose an internal class...

1.) Add the search bar to KWebView's parent widget layout when it is first 
created and call update on the layout. This is a matter of adding few lines of 
code to what is now KWebView::searchBar() and changing that function into a 
slot that gets invoked when CTRL+F is pressed. I have done this in my local 
copy and it works. However, this is not a robust solution at all! What if the 
application using kdewebkit wants to add its own widgets such as a save 
password bar (KWallet integration) for example ? 

2.) For a more robust solution we need to do something like what KHTML does. 
It has a KHTMLViewBar class which manages widgets you want to add to the view. 
KHTML then creates two instance of the view bar, one at the top and bottom, 
and allow you to add your own widgets to these bars. This is what KHTML uses 
to add the password and search bar widgets to its view. We can do the a 
similar thing by creating a public KWebViewBar class and exposing the 
instances we create through public member functions, e.g. topViewBar() and 
bottomViewBar(). This is probably a better approach in the long run, no ?