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

[Simon Hausmann]

On Tuesday, February 05, 2013 10:27:01 AM José Dapena Paz wrote:
> El mar, 05-02-2013 a las 10:16 +0100, Simon Hausmann escribió:
> > > I think it could be possible to keep compatibility at least between
> > > minor version numbers. "qtwebkit" repository could at least make sure it
> > > doesn't add API/ABI changes once a stable release is done. This would
> > > likely be enough warranty for most uses.
> > 
> > If with "minor" you mean between "patch" releases of Qt, then yes. Since
> > we
> > usually don't take new snapshots from trunk between patch releases but
> > only
> > for minor releases of Qt, the API would only change then.
> 
> Yes, that's what I meant. For me it looks like a very good idea (in the
> case of the issues I'm checking, html5 notification and spellchecking),
> it would simplify things a lot.
> 
> So, with this new approach, my main doubt is where would the
> enchant-specific API fit best. I guess I could create something like
> WKTextCheckerEnchant, with the specific methods. And I could make qt
> load the enchant implementation by default. And by default use as
> languages the ones in environment.
> 
> My main doubt in this case would be if I should also add a method to set
> Enchant implementation as client. Something like
> "WKTextCheckerEnchantSetAsClient", that would call
> WKTextCheckerEnchantSetClient with the Enchant implementation. Or even a
> method like "WKTextCheckerIsEnchant" to be able to check if loaded
> client is Enchant.

Yes, that's theoretically possible. The main issue I see with that is that the 
WKTextChecker API also delegates bits of the UI handling, which makes it not 
entirely obvious how to share a Qt/Gtk/EFL common Enchant based implementation 
with an application specific UI (not even toolkit specific!).

I suppose the clients could be chained, i.e. an enchant based spell checker 
provides an API that delegates the UI bits to the app and itself implements 
the full WKTextCheckerClient.

That leaves us with an API that is only available on certain platforms in 
certain situations. But certainly allows for code sharing between the ports.

Simon