[webkit-qt] Spellchecking support for WebKit2

[José Dapena Paz]

El lun, 21-01-2013 a las 16:19 +0100, Simon Hausmann escribió:

> Okay, I see.
> 
> A bunch of us are going to have a face-to-face workshop next week and one of 
> the things I'd like to tackle there is an extensive API review of additions 
> for the release for Qt 5.1. How exactly to deal with global settings such as 
> the ones you describe is a topic I hope to resolve there.
> 
> I'll make sure to send an email with our conclusions for a wider discussion.

Good! Please take into account in the discussion both the spellcheck
approach in latest patch (just some public settings) and the other mail
I sent last week about global settings.

> > 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.
> 
> Not sure I totally understand the idea of exposing common API from WebCore, 
> but I certainly like the idea of splitting up work into smaller pieces ;-)

So, after latest changes:
* Implementation done using enchant.
* No c++ public API at all for accessing the spellchecker and change it.
* QWebGlobal (webkit var in QML) has 3 properties: textCheckerEnabled
(read/write), textCheckerLanguages (read/write) and
textCheckerAvailableLanguages (read only).
* Disabled build by default of spellcheck support. WEBKIT_CONFIG
+=spellcheck is required now.
* Removed the use(enchant) var. If we are building with spellcheck
support we require enchant.

So, next steps (and questions)...

Let's see the result of the Qt 5.1 API meeting, to figure out the final
API for accessing the text checker properties.

Now spellcheck is disabled by default. I see 3 options:
* Keep it disabled
* Enable it by default (and add enchant to the buildmachine)
* Enable it only if enchant is available (and again add enchant to build
machine).

Adding a new text checker at WK2 level will be as much easy as just
loading a different WKSpellCheckClient, so this would be enough to add a
different implementation. Also, we use enchant, so another way to change
the implementation is just add new providers to enchant. So I guess I'll
be ok with current implementation.