On Friday, January 18, 2013 11:54:00 AM José Dapena Paz wrote: > El jue, 10-01-2013 a las 12:13 +0100, Simon Hausmann escribió: > > > But for me it is obvious that adding support at toolkit level, and then > > > make any Qt stock editing widget/component be able to use it would be > > > quite interesting. At WebKit level, we would then just use Qt API as the > > > default implementation for text checking. > > > > Sounds good. It can be done in increments after all, i.e. use a library > > directly in WebKit first and later maybe a component/API from the toolkit. > > My take on this, after working a bit with the patch, is completely > removing anything that's not needed at UI level from QML API. So, we are > exposing only this: > * Enable > * Languages enabled > * Languages available > > This is the minimum to provide a UI as the ones usually seen in > applications like Chrome or Firefox.
Yes, and this is theoretically per webview, right? > > > Typical UI case (you can find settings for this in at least firefox and > > > chrome): > > > * Being able to enable/disable spell checking. > > > * Choose the set of languages to do spell checking. But it defaults to > > > user desktop language. To do this you need to know the spell check > > > engine supported languages and have a way to set them. > > > > Right, _this_ is where we may have to make a distinction between toolkit > > level support or not. If not, then we do need a API on the WebKit level. > > If it's minimal then we can also add it there first and later make it > > delegate to the toolkit implementation. > > > > In general it seems to me that as a developer _embedding_ WebKit I don't > > want to have to make a choice about which spell checking _engine_ to use. > > Therefore I think that part should be left out from the API. > > My take on this: > * Expose only the minimum API to QML (the 3 vars above). > * At C++ level, expose the abstract class for QWebTextChecker, and allow > to change stock implementation. > > Is it ok? > > As we don't have any platform plugin, the other alternative I see would > be just not exposing the text checker abstract class, and make > implementors add other spellcheckers on the WebCore/platform tree. And > then add also a way to choose the one for platform build time. I suggest to go for the latter approach, i.e. not offer a C++ level API for custom spell checking. Making a custom spell checker seems like a rare use-case that justifies the use of a low-level API or contributing it to the platform itself. I'm still quite fond of the idea of making the C API the cross-port low-level API for purposes like these, and indeed it already provides this functionality. Simon _______________________________________________ webkit-qt mailing list webkit-qt@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-qt
