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