[webkit-qt] Spellchecking support for WebKit2
simon.hausmann at digia.com
Mon Jan 21 07:19:25 PST 2013
On Monday, January 21, 2013 02:37:32 PM José Dapena Paz wrote:
> El lun, 21-01-2013 a las 13:30 +0100, Simon Hausmann escribió:
> > 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?
> No, there's only 1 global for this in WebKit2 platform. So you only have
> a spellchecker shared among the web views. If it would be per view, we
> could just put these settings already on QWebPreferences. But in this
> case I need some way to expose these variables (see my other mail about
> an object for exposing global properties).
Okay, I see.
A bunch of us are going to have a face-to-face workshop next week and one of
the things I'd like to tackle there is an extensive API review of additions
for the release for Qt 5.1. How exactly to deal with global settings such as
the ones you describe is a topic I hope to resolve there.
I'll make sure to send an email with our conclusions for a wider discussion.
> > > 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.
> In fact, for me, the main problem now is that there's no common API for
> spellchecker directly at WebCore. It could be quite interesting that the
> WebTextCheckerEnchant in WebCore implemented some kind of interface, so
> that any other implementation would fall there. But anyway, that's a
> different issue.
> So, what I'll do is just drop almost all the C++ API, and limit the vars
> to the ones required now. I could, in another step, try to expose some
> kind of common API from WebCore, so that it is easy to provide other
> platform checkers.
Not sure I totally understand the idea of exposing common API from WebCore,
but I certainly like the idea of splitting up work into smaller pieces ;-)
More information about the webkit-qt