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

[Kenneth Rohde Christiansen]

Btw, we EFL might move to a purely Hunspell implementation (probably
the Chrome one)

Kenneth

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



-- 
Kenneth Rohde Christiansen
Senior Engineer, WebKit, Qt, EFL
Phone  +45 4294 9458 / E-mail kenneth at webkit.org

﹆﹆﹆