Hunspell based spellchecker
Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work. Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand. For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc. BTW, here is an under-half-baked-rough plan: - Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like "TextChecker* textChecker() = 0;" to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.) Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome. -- morrita
Hi Hajime, On Nov 16, 2010, at 8:52 PM, Hajime Morita wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work.
Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand.
For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc.
BTW, here is an under-half-baked-rough plan:
- Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like "TextChecker* textChecker() = 0;" to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient
This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.)
Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome.
The wx port is very interested. :) I think this design would do everything that our port needs. We'd probably use the native spellchecker on Mac, and Hunspell on other platforms for now. Thanks, Kevin
-- morrita _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi Hajime, I was looking to implement EditorClientQt::checkSpellingOfString() stub for the qt port. This is part of an effort to enable red squiggle markers for misspelled text. We'd like to show the markers for any editable content when rendering with qtwebkit based browsers. This would rely on a spelling engine but, as qt has no spell checker, Hunspell integration to WebCore seems appealing. I was headed in this direction when I found this thread and I wonder if you are still pursuing this. Can you tell me if it is a worthwhile pursuit, or if you had problems? I'm interested in continuing, but give me a "heads up" if you were blocked for some reason. Thanks! Fabrizio On Nov 16, 2010, at 8:52 PM, Hajime Morita wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work.
Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand.
For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc.
BTW, here is an under-half-baked-rough plan:
- Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like "TextChecker* textChecker() = 0;" to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient
This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.)
Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome.
-- morrita _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Wed, Jan 26, 2011 at 1:52 PM, Fabrizio Machado <fabrizio.machado123@gmail.com> wrote:
This would rely on a spelling engine but, as qt has no spell checker, Hunspell integration to WebCore seems appealing.
I was headed in this direction when I found this thread and I wonder if you are still pursuing this.
Can you tell me if it is a worthwhile pursuit, or if you had problems? I'm interested in continuing, but give me a "heads up" if you were blocked for some reason.
For what it is worth, the approach outlined by Hajime would also be useful for the Haiku port I am working on. I was already considering porting Hunspell to Haiku and making use of it in the Haiku port, but if multiple ports could benefit all the better. It seems like the TextCheckerClient approach is reasonable if it is architected in the same way as EditorClient and friends. The Hunspell based TextChecker could live in WebCore and link with Hunspell and would only be compiled and used by ports which need it. There would still need to be a TextCheckerClient in WebCoreSupport in WebKit to call to the TextCheckerHunspell or whatever in WebCore. Maybe this still isn't the right architecture but I don't think it is impossible to implement this in a way which matches other uses in WebKit. -- Regards, Ryan
Fabrizio, Ryan, thank you for your interest! Although I'm suspending the work at this time, your interest gives me a good reason to restart ;-) I'll CC you in bug(s) and post some status there within weeks. Regards. ---- morrita On Thu, Jan 27, 2011 at 4:23 AM, Ryan Leavengood <leavengood@gmail.com> wrote:
On Wed, Jan 26, 2011 at 1:52 PM, Fabrizio Machado <fabrizio.machado123@gmail.com> wrote:
This would rely on a spelling engine but, as qt has no spell checker, Hunspell integration to WebCore seems appealing.
I was headed in this direction when I found this thread and I wonder if you are still pursuing this.
Can you tell me if it is a worthwhile pursuit, or if you had problems? I'm interested in continuing, but give me a "heads up" if you were blocked for some reason.
For what it is worth, the approach outlined by Hajime would also be useful for the Haiku port I am working on. I was already considering porting Hunspell to Haiku and making use of it in the Haiku port, but if multiple ports could benefit all the better.
It seems like the TextCheckerClient approach is reasonable if it is architected in the same way as EditorClient and friends. The Hunspell based TextChecker could live in WebCore and link with Hunspell and would only be compiled and used by ports which need it. There would still need to be a TextCheckerClient in WebCoreSupport in WebKit to call to the TextCheckerHunspell or whatever in WebCore. Maybe this still isn't the right architecture but I don't think it is impossible to implement this in a way which matches other uses in WebKit.
-- Regards, Ryan _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- morrita
On Wed, Jan 26, 2011 at 6:24 PM, Hajime Morita <morrita@google.com> wrote:
Fabrizio, Ryan, thank you for your interest!
Although I'm suspending the work at this time, your interest gives me a good reason to restart ;-)
Good to hear! I think having 3 or 4 possible ports being able to use this is enough reason for it to be implemented. Let's just be sure the design you intend to implement fits within the WebCore/WebKit design so it can be included once you are done.
I'll CC you in bug(s) and post some status there within weeks.
Sounds good. I have plenty of other things to keep me busy in the meantime on the Haiku WebKit port as well as our browser project. -- Regards, Ryan
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
The Qt folks on the list can correct me if I'm wrong but this would be very welcome for Qt. I don't see how a WebCore spellchecker could be anything but a good thing!
It is. See https://bugs.webkit.org/show_bug.cgi?id=44114 On Wed, Nov 17, 2010 at 1:43 PM, Robert Hogan <lists@roberthogan.net> wrote:
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
The Qt folks on the list can correct me if I'm wrong but this would be very welcome for Qt. I don't see how a WebCore spellchecker could be anything but a good thing!
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- --Antonio Gomes
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
At least in the Windows implementation (WebKit/WebKit source base), the spell checker is implemented on the client side as a delegate operation. I wrote up a few notes on the topic (http://whtconstruct.blogspot.com/2010/07/spelling.html). What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure? -Brent
Hi, Multiple ports can share the implementation if we put spell checker in WebCore. Ports without native spell checker can use Hunspell based spell checker without much efforts. Brew MP port is also interested because it does not have a native spell checker. Regards, Kwang Yul Seo On Thu, Nov 18, 2010 at 5:27 AM, Brent Fulgham <bfulgham@gmail.com> wrote:
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
At least in the Windows implementation (WebKit/WebKit source base), the spell checker is implemented on the client side as a delegate operation.
I wrote up a few notes on the topic (http://whtconstruct.blogspot.com/2010/07/spelling.html).
What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure?
-Brent _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi everyone, thank you for your feedback! Now I know there are some positive interest to Hunspell integration. So I'll start investigation and come back once I have some progress. @bflgham
What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure? As @kwangyul.seo mentioned, the primary advantage of WebCore-ization is code sharing. Having it, you can get working integration with few effort. And yes, if you already have your own implementation, there might be no direct benefit.
As a developer's standpoint, centralizing spellcheck related code into WebCore will make it much easier to work on spellchecking related codebase. As you know, touching every ports' EditingClient implementation is plain pain. It is another story though. -- morrita
-Brent _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- morrita
Safari on Windows provides a spelling checker outside of WebKit. If we change the way spelling checking is organized inside WebKit, we need to preserve that feature in the WebKit used by Safari on Windows. -- Darin
On Thu, Nov 18, 2010 at 3:33 PM, Darin Adler <darin@apple.com> wrote:
Safari on Windows provides a spelling checker outside of WebKit. If we change the way spelling checking is organized inside WebKit, we need to preserve that feature in the WebKit used by Safari on Windows. Thank you for pointing this out. In my understanding, windows port is using EditingDelegate implementation for EditorClient. I think we can also use same EditingDlegate to implement TextChecker (or something like that) interface.
In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore. I need to investigate more to see whether it is possible. Anyway, I'll start keeping original EditorClient API, then try to remove unnecessary methods. The change looks too large to do it at once. -- morrita
On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote:
In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore.
Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API. A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API. -- Darin
On Thu, Nov 18, 2010 at 3:51 PM, Darin Adler <darin@apple.com> wrote
On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote:
In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore.
Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API.
A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API.
Hmm, I'm a bit confused - My last explanation looks not enough, so please let me clarify: - TextChecker is a similar to EditorClient. It will be placed in WebCore/platform/text, like EditorClient is in WebCore/page/. - And (imaginative) WebTextChecker (or TextCheckerWindows) will be in WebKit/win/WebCoreSupport, as WebEditorClient is in WebKit/win/WebCoreSupport. - WebTextChecker should use EditingDelegate, as WebEditorClient is using it now. In other word, This change will just extract TextChecker interface from EditrClient interface, and provide some default implementations of it in WebCore, as we have WebCore/page/EmptyEditorClient for EditorClient. I guess we don't have this "Interface in WebCore + Implementation in WebCore and WebCoreSupport" pattern yet, But I don't think it is such a huge jump from existing patterns, like "Interface in WebCore + Implementation in WebCoreSupport". Does this make sense? -- morrita
-- Darin
-- morrita
On Nov 17, 2010, at 11:44 PM, Hajime Morita wrote:
On Thu, Nov 18, 2010 at 3:51 PM, Darin Adler <darin@apple.com> wrote
On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote:
In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore.
Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API.
A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API.
Hmm, I'm a bit confused - My last explanation looks not enough, so please let me clarify:
- TextChecker is a similar to EditorClient. It will be placed in WebCore/platform/text, like EditorClient is in WebCore/page/. - And (imaginative) WebTextChecker (or TextCheckerWindows) will be in WebKit/win/WebCoreSupport, as WebEditorClient is in WebKit/win/WebCoreSupport. - WebTextChecker should use EditingDelegate, as WebEditorClient is using it now.
In other word, This change will just extract TextChecker interface from EditrClient interface, and provide some default implementations of it in WebCore, as we have WebCore/page/EmptyEditorClient for EditorClient.
I guess we don't have this "Interface in WebCore + Implementation in WebCore and WebCoreSupport" pattern yet, But I don't think it is such a huge jump from existing patterns, like "Interface in WebCore + Implementation in WebCoreSupport".
Does this make sense?
"Interface in WebCore + Implementation in WebCore and WebCoreSupport" doesn't match WebKit's normal approach to layering. Our approach so far (for ports other than Chromium) has been to make it possible to link WebCore separately, and therefore only have dependencies from WebCore to WebKit, not vice versa. If WebCore functionality needs to call up to WebKit, we use an abstract interface in WebCore which WebKit then implements, i.e. the client pattern. Regards, Maciej
On Fri, Nov 19, 2010 at 4:02 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On Nov 17, 2010, at 11:44 PM, Hajime Morita wrote:
On Thu, Nov 18, 2010 at 3:51 PM, Darin Adler <darin@apple.com> wrote
On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote:
In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore.
Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API.
A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API.
Hmm, I'm a bit confused - My last explanation looks not enough, so please let me clarify:
- TextChecker is a similar to EditorClient. It will be placed in WebCore/platform/text, like EditorClient is in WebCore/page/. - And (imaginative) WebTextChecker (or TextCheckerWindows) will be in WebKit/win/WebCoreSupport, as WebEditorClient is in WebKit/win/WebCoreSupport. - WebTextChecker should use EditingDelegate, as WebEditorClient is using it now.
In other word, This change will just extract TextChecker interface from EditrClient interface, and provide some default implementations of it in WebCore, as we have WebCore/page/EmptyEditorClient for EditorClient.
I guess we don't have this "Interface in WebCore + Implementation in WebCore and WebCoreSupport" pattern yet, But I don't think it is such a huge jump from existing patterns, like "Interface in WebCore + Implementation in WebCoreSupport".
Does this make sense?
"Interface in WebCore + Implementation in WebCore and WebCoreSupport" doesn't match WebKit's normal approach to layering. Our approach so far (for ports other than Chromium) has been to make it possible to link WebCore separately, and therefore only have dependencies from WebCore to WebKit, not vice versa. If WebCore functionality needs to call up to WebKit, we use an abstract interface in WebCore which WebKit then implements, i.e. the client pattern.
Agreed. And I realized that my last explanation was not clear enough again ... I'm sorry for confusion. In this proposal, we will have: - WebCore::TextChecker interface (or TextCheckingClient interface, to follow our usual naming) - WebCore::TextCheckerHunspell class, implementing WebCore::TextCheckingClient - (WebKit::)WebTextChecker class, implementing WebCore::TextCheckingClient. There is no explicit dependency from WebCore to WebKit. WebCore::Editor will depend WebCore::TextCheckingClient, whose implementation might be in WebKit. -- morrita
Regards, Maciej
-- morrita
Greetings Hajime-san, Even though this is out of this topic, from the point of a web-application developer, it would be great for WebKit to have a JavaScript API that encapsulates your spellchecker code so JavaScript can use it. Regards, Hironori Bono E-mail: hbono@chromium.org On Wed, Nov 17, 2010 at 1:52 PM, Hajime Morita <morrita@google.com> wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work.
Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand.
For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc.
BTW, here is an under-half-baked-rough plan:
- Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like "TextChecker* textChecker() = 0;" to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient
This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.)
Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome.
-- morrita _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi Bono-san,
Even though this is out of this topic, from the point of a web-application developer, it would be great for WebKit to have a JavaScript API that encapsulates your spellchecker code so JavaScript can use it. It sounds interesting. Because we need standardized(or standardizable) proposal for Web-facing API in general, public-webapps or whatwg list would be good place to start. Any suggestions are welcome. And I'll also investigate this further.
Regards. -- morrita On Sun, Apr 24, 2011 at 8:26 PM, Hironori Bono (坊野 博典) <hbono@chromium.org> wrote:
Greetings Hajime-san,
Even though this is out of this topic, from the point of a web-application developer, it would be great for WebKit to have a JavaScript API that encapsulates your spellchecker code so JavaScript can use it.
Regards,
Hironori Bono E-mail: hbono@chromium.org
On Wed, Nov 17, 2010 at 1:52 PM, Hajime Morita <morrita@google.com> wrote:
Hi WebKit folks,
I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore.
Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work.
Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand.
For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc.
BTW, here is an under-half-baked-rough plan:
- Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like "TextChecker* textChecker() = 0;" to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient
This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.)
Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome.
-- morrita _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-- morrita
participants (11)
-
Antonio Gomes
-
Brent Fulgham
-
Darin Adler
-
Fabrizio Machado
-
Hajime Morita
-
Hironori Bono (坊野 博典)
-
Kevin Ollivier
-
KwangYul Seo
-
Maciej Stachowiak
-
Robert Hogan
-
Ryan Leavengood