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 <[email protected]> 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 > [email protected] > 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 ﹆﹆﹆ _______________________________________________ webkit-qt mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-qt
