[webkit-qt] Spellchecking with C API (was: APIs going forward)

Simon Hausmann simon.hausmann at digia.com
Tue Feb 5 02:49:43 PST 2013

On Tuesday, February 05, 2013 11:37:53 AM José Dapena Paz wrote:
> El mar, 05-02-2013 a las 11:21 +0100, Kenneth Rohde Christiansen
> escribió:
> > Isnt that the exact reason why there is a WK C API for replacing the
> > default spell checker?
> In fact, yes. I could add a text checker client using our internal API
> just using WK C API. So yes, we don't really depend on Enchant, and we
> could use any other backend by default.
> The thing is that we already have an implementation working for Enchant,
> and it is already used in other ports. I wouldn't mind adding a new
> default implementation later, but I'd really need to have something
> working soon.
> So, please check if this plan makes sense:
> 1. (me) Finish spellchecking support to Qt port. For TextCheckerClient
> we provide an enchant based default implementation using WebCore
> TextCheckerEnchant, and a C API for changing checked language and
> setting it as the spellchecker.
> 2. (someone else interested) Create a new implementation (hunspell,
> chrome hunspell, or whatever). Add a C API to set languages, whatever is
> needed to customize how hunspell works for the app.
> 3. Once it is checked the new implementation is realiable and better
> than enchant, just drop old implementation.

I'm not sure that plan is going to work out in the sense that step (3) doesn't 
usually combine very well with "I'd really need to have something working 

For trunk let's at least try to find a concensus across Efl/Gtk/Qt. Do we need 
another small ports IRC meeting? :)


More information about the webkit-qt mailing list