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

José Dapena Paz jdapena at igalia.com
Wed Feb 6 02:18:34 PST 2013


El mar, 05-02-2013 a las 11:49 +0100, Simon Hausmann escribió:
> 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 
> soon".

Another possibility is just not provide any implementation. Just add the
TextChecker.h qt implementation and relay on the WKTextCheckerClient
set. Apps would be able to add their custom implementation from minute
one, and we wouldn't be depending on any implementation being done.





More information about the webkit-qt mailing list