Moving hunspell-based checker into WebKit?

[Hajime Morita]

Hi,

I'm looking around the spellchecker code.
And I found that a part of that code might not need to stay inside the Chromium;
A part of Hunspell related code possibly can live in the WebKit land.
It will help GTK/Qt ports of WebKit, which currently don't have
spellchecking feature.

I asked hbono@, and he told me that there is some tricky stuff like
downloading dictionary data and system spellchecker integration, etc.

Then I wonder:
- First of all, whether is it good for us, to contribute Hunspell
based spellchecker to WebKit?
- How hard is it to do? Which is a possible blocker?
- Is there good way to do it?

My current feeling is:
- it is possible, but need small WebKit API change.
- it would be useful for other WebKit community.

Any thoughts?
Your ideas/suggestions are welcome.
I'll propose this on webkit-dev if it looks fine.

--
morrita

[Marshall Greenblatt]

I think having spell checking as part of the Chromium WebKit API would be cool.
 

--
morrita

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[Darin Fisher]

It would probably be very helpful to get Brett Wilson's input on this as he was responsible for much of the hunspell integration.  There may be some gotchas that he might know of.

-Darin

[Tony Chang]

Have you asked the GTK+/QT people if they are interested in using hunspell?  I would think that GTK+ would want to use Enchant (which gtkspell uses) which provides integration with other GTK+ apps.

I'm not very familiar with QT, but there doesn't seem to be spellchecking as part of the platform, so maybe it doesn't matter as much for them.

On Mon, Nov 15, 2010 at 10:01 PM, Hajime Morita <mor...@google.com> wrote:

[Evan Martin]

Similarly, I expect the Safari WebKit to not want a spell checker
other than the native system one.

[Hajime Morita]

Hi everyone, thank you for your feedback!

Overall, I didn't find any strong objection, but some concerns on
other WebKit ports.
And there looks some gotcha on Chrome I/O model, etc. that I should manage.

I'll ask this on webkit-dev whether they have any interest.
Because this change will bring no benefit without interests from other ports.

Comments inline:

@brettw, @darin
> What problem are you trying to solve?
It's not directly for Chrome itself,
What I thought is that our hunspell integration might be useful for
other WebKit port,
and we can contribute them.
I found many spellcheck related tests on WebKit are skipped.
If we can make them passed, it would be easier to work on spellcheck related
code on WebKit side. Skipping new tests makes me sad.

> dictionary downloading, system integration,
> and the Chrome. I/O model and would not be beneficial to other
> platforms.
Yes. So I think these part should be kept in the Chrome.
Current interest is for word iterator and Hunspell API wrapper.

@magreenblatt

> I think having spell checking as part of the Chromium WebKit API would be cool.

My first thought is move spellcheck code "inside" the webkit (more
specifically, WebCore.)
But yes, exposing it as a Chromium API looks useful. Thank you for
pointing this out.

@thakis
>I just wanted to point out that we use the system spellchecker instead
>of Hunspell in Chrome/Mac as far as I know, and we'd like to keep it
>that way. As long as you don't break this usecase, I'm happy.
Of course! This is another tricky part.
My current thinking is that the system spellcheck integration could be
moved behind
ChromiumBridge, instead of WebKitClient.

@tony

>Have you asked the GTK+/QT people if they are interested in using hunspell? I would think >that GTK+ would want to use Enchant (which gtkspell uses) which provides integration with >other GTK+ apps.

>
>I'm not very familiar with QT, but there doesn't seem to be spellchecking as part of the >platform, so maybe it doesn't matter as much for them.

I didn't asked them yet, and I didn't notice gtkspell! Thank you for
letting me know this.
I'll ask them soon, assuming we Chromium side don't have strong
opposition at this time.

@evan

> Similarly, I expect the Safari WebKit to not want a spell checker
> other than the native system one.

Sure. They have NSSpellChecker so this porting will/should not affect them.

--
morrita

--
morrita

[Hajime Morita]

On Thu, Nov 18, 2010 at 7:36 AM, Brett Wilson <bre...@google.com> wrote:

> On Tuesday, November 16, 2010, Hajime Morita <mor...@google.com> wrote:
>> Hi everyone, thank you for your feedback!
>>
>> Overall, I didn't find any strong objection, but some concerns on
>> other WebKit ports.
>> And there looks some gotcha on Chrome I/O model, etc. that I should manage.
>>
>> I'll ask this on webkit-dev whether they have any interest.
>> Because this change will bring no benefit without interests from other ports.
>>
>> Comments inline:
>>
>> @brettw, @darin
>>> What problem are you trying to solve?
>> It's not directly for Chrome itself,
>> What I thought is that our hunspell integration might be useful for
>> other WebKit port,
>> and we can contribute them.
>> I found many spellcheck related tests on WebKit are skipped.
>> If we can make them passed, it would be easier to work on spellcheck related
>> code on WebKit side. Skipping new tests makes me sad.
>>
>>> dictionary downloading, system integration,
>>> and the Chrome. I/O model and would not be beneficial to other
>>> platforms.
>> Yes. So I think these part should be kept in the Chrome.
>> Current interest is for word iterator and Hunspell API wrapper.
>

> I agree that running the layout tests would be useful but I'm not sure
> the value to other ports is very high given the simplicity of the API
> and differring requirements.
I think they have long queue to catch up recent HTML5 effort and
spellchecking looks behind the list...
I've asked webkit-dev about this, and got a some positive feedback.
https://lists.webkit.org/pipermail/webkit-dev/2010-November/015083.html

>
> I would also be concerned about duplication of code if we moved the
> word iterator. The current code has unit tests (I think) and is shared
> with other Chrome code, and I wouldn't want to lose that.
Good point. I didn't think about this.

For unit test, I'm thinking it can and should be ported to WebKit
(under WebKit/chromium/tests/*)
I couldn't find where the Spellcheck and associated class is used.
(The browser process only uses system spellchecker.)
It looks safe to move it into WebKit. though I don't have enough confident.

So I'll try a prototypical work and ask you for more feedback,
once I have something playable.
Thanks much for sharing your insight!

Regards.
--
morrita

>
> Brett