[webkit-qt] Spellchecking support for WebKit2

[Simon Hausmann]

On Friday, January 18, 2013 11:54:00 AM José Dapena Paz wrote:
> El jue, 10-01-2013 a las 12:13 +0100, Simon Hausmann escribió:
> > > But for me it is obvious that adding support at toolkit level, and then
> > > make any Qt stock editing widget/component be able to use it would be
> > > quite interesting. At WebKit level, we would then just use Qt API as the
> > > default implementation for text checking.
> > 
> > Sounds good. It can be done in increments after all, i.e. use a library
> > directly in WebKit first and later maybe a component/API from the toolkit.
> 
> My take on this, after working a bit with the patch, is completely
> removing anything that's not needed at UI level from QML API. So, we are
> exposing only this:
>    * Enable
>    * Languages enabled
>    * Languages available
> 
> This is the minimum to provide a UI as the ones usually seen in
> applications like Chrome or Firefox.

Yes, and this is theoretically per webview, right?
 
> > > Typical UI case (you can find settings for this in at least firefox and
> > > chrome):
> > > * Being able to enable/disable spell checking.
> > > * Choose the set of languages to do spell checking. But it defaults to
> > > user desktop language. To do this you need to know the spell check
> > > engine supported languages and have a way to set them.
> > 
> > Right, _this_ is where we may have to make a distinction between toolkit
> > level support or not. If not, then we do need a API on the WebKit level.
> > If it's minimal then we can also add it there first and later make it
> > delegate to the toolkit implementation.
> > 
> > In general it seems to me that as a developer _embedding_ WebKit I don't
> > want to have to make a choice about which spell checking _engine_ to use.
> > Therefore I think that part should be left out from the API.
> 
> My take on this:
> * Expose only the minimum API to QML (the 3 vars above).
> * At C++ level, expose the abstract class for QWebTextChecker, and allow
> to change stock implementation.
> 
> Is it ok?
> 
> As we don't have any platform plugin, the other alternative I see would
> be just not exposing the text checker abstract class, and make
> implementors add other spellcheckers on the WebCore/platform tree. And
> then add also a way to choose the one for platform build time.

I suggest to go for the latter approach, i.e. not offer a C++ level API for 
custom spell checking.

Making a custom spell checker seems like a rare use-case that justifies the use 
of a low-level API or contributing it to the platform itself. I'm still quite 
fond of the idea of making the C API the cross-port low-level API for purposes 
like these, and indeed it already provides this functionality.


Simon