[webkit-qt] Spellchecking support for WebKit2

[José Dapena Paz]

El lun, 21-01-2013 a las 13:30 +0100, Simon Hausmann escribió:
> 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?

No, there's only 1 global for this in WebKit2 platform. So you only have
a spellchecker shared among the web views. If it would be per view, we
could just put these settings already on QWebPreferences. But in this
case I need some way to expose these variables (see my other mail about
an object for exposing global properties).

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

In fact, for me, the main problem now is that there's no common API for
spellchecker directly at WebCore. It could be quite interesting that the
WebTextCheckerEnchant in WebCore implemented some kind of interface, so
that any other implementation would fall there. But anyway, that's a
different issue.

So, what I'll do is just drop almost all the C++ API, and limit the vars
to the ones required now. I could, in another step, try to expose some
kind of common API from WebCore, so that it is easy to provide other
platform checkers.