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

[Simon Hausmann]

On Tuesday, February 05, 2013 11:04:16 AM Kenneth Rohde Christiansen wrote:
> Btw, we EFL might move to a purely Hunspell implementation (probably
> the Chrome one)

Then we should clearly share that with you. There's little point in diverging 
here :)


Simon

> On Tue, Feb 5, 2013 at 10:59 AM, Simon Hausmann
> 
> <simon.hausmann at digia.com> wrote:
> > 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
> > _______________________________________________
> > webkit-qt mailing list
> > webkit-qt at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-qt