Thanks all for the input. I've successfully implemented basic spellchecking using the OSX spellchecker, although the implementation is a bit untested, so I'm trying to get that cleaned up a little bit before moving any more forward. As for keeping hunspell or not, I've left it there, it isn't take much work to keep it around, since the code is already there and working. It should work more or less as Sid mentioned, only taking over when OSX doesn't support the language. The design on the whole didn't change too much from what I originally talked about above, although I have added the calls into cocoa as wrapper functions in a seperate file.
The main issues I still have to work out for basic spellchecker functionality (not the spelling panel) mainly revolve around language selection. It's a bit unclear to me how the language of the spellchecker is changed, since the only place to specify it is in the constructor to the spellchecker. I don't see any other functions/methods that deal with language selection. I was going to try and trace this through in the debugger, but the button on the options pane to change the language is greyed out. Anybody know anything about how this works or can point me in the right direction (or is this the not-implemented piece that Sid mentioned)? -Paul Wicks On Thu, Jun 11, 2009 at 11:59 AM, sidchat <sidc...@chromium.org> wrote: > > Use of OS X spellchecker integration in our multi process model > probably should be the primary goal here to begin with. If that is > achieved, the other stuff (auto spell correct, automatically setting > the dictionary etc) should not be too problematic. > > Note that the actual replacement for auto-correct is done in WebCore > (WebKit) - Chrome just provides the decision as to whether to auto- > correct it or not. So, as you pointed out, our method SpellcheckWord, > instead of using Hunspell, can ask OS X SpellCheck API to provide the > decision. The multi-process model is automatically taken care of here > from existing design, since any query for spellchecking comes to the > spellchecker in the browser process - and the browser process can talk > to the OS X API I guess. Same goes for generic spell checking. > > There is some integration with Chrome UI where one can set the > spellcheck dictionary languages, enable/disable spellchecking/auto- > correct. Again, all these decisions eventually seep down to the > spellchecker residing in the browser process, and as far as you are > concerned, the SpellCheckWord and GetAutoCorrectWord methods should > continue asking OS X for the spelling decisions, now based on the new > language, or not, depending on the setting. > > If OS X does not support some languages, this can be dealt with > easily. You can make a list of languages that OS X supports, and based > on that, either ask OS X spellcheck API, or simply initialize Hunspell > in SpellChecker when the language is changed. The Profile, which > initializes spellchecker, can be blissfully unaware of this, as it > does not care how you are providing the spellchecking as long as the > spellchecker object exists, and is providing decisions. > > I am not exactly sure how automatically setting dictionary language > will work out, as it has not been implemented yet. But you can get to > that later - my thought is, it should be on similar lines, where you > have to only worry about spellchecker.cc. > > -Sid > > > On Jun 10, 8:29 pm, "Ben Goodger (Google)" <b...@chromium.org> wrote: > > +Sid > > > > I think it's worth understanding the API requirements of the new > > features. I know nothing about Spellchecking though. Maybe Sid can add > > more? > > > > -Ben > > > > > > > > On Wed, Jun 10, 2009 at 8:14 PM, Nick Baum<nickb...@chromium.org> wrote: > > > In particular, Ben is referring to the automatic spelling correction > that > > > Sid is implementing. > > > Off the top of my head, I can think of a few different ways this could > fit > > > in: > > > > > We can implement Sid's auto-correction on top of native spellcheck, > just > > > like today it's implemented on top of Hunspell. > > > OS X will provide similar (though not identical) functionality, and we > deem > > > this good enough. > > > We decide native integration is more important than feature parity. As > we > > > add more smarts to the spellchecker, we'd need to keep re-evaluating. > > > > > Thoughts? > > > -Nick > > > > > On Wed, Jun 10, 2009 at 2:38 PM, Ben Goodger (Google) < > b...@chromium.org> > > > wrote: > > > > >> For whoever is coordinating this effort, please sync up with Nick Baum > > >> on spell checking. He has some additional considerations in mind we > > >> should make sure we understand what's possible here. > > > > >> -Ben > > > > >> On Wed, Jun 10, 2009 at 2:36 PM, Mike Pinkerton< > pinker...@chromium.org> > > >> wrote: > > > > >> > I think we're all on the same page. I pushed Paul to consider having > > >> > both in his initial design since I forgot about the ability to add > > >> > additional dictionaries. I'm glad others are in support of that as > the > > >> > way to get additional language support as opposed to trying to shim > > >> > both implementations together. > > > > >> > I agree with Jeremy, let's focus on the OSX spellchecker and ignore > > >> > hunspell for now. Additionally, let's aim for the OS X spelling > dialog > > >> > if we can do it, regardless of whether or not win/linux can do it. > > > > >> > On Wed, Jun 10, 2009 at 11:59 AM, Thomas Van > > >> > Lenten<thoma...@chromium.org> wrote: > > > > >> >> On Wed, Jun 10, 2009 at 2:38 PM, p_W <paulwoolcoc...@gmail.com> > wrote: > > > > >> >>> Forgive my (possibly) stupid concern here, but a few months ago > there > > >> >>> was some talk about this, and about how integrating with the OS's > > >> >>> spellchecker was the preferred route as it allowed users to use > their > > >> >>> dictionary customizations over all their applications. Here is > link > > >> >>> to the discussion: > > > > >> >>> > http://groups.google.com/group/chromium-dev/browse_thread/thread/3183... > > > > >> >>> Any thoughts about this? > > > > >> >> Uh, that's what this thread is about, his project is to switch to > using > > >> >> the > > >> >> os one instead. And Jeremy was commenting that he doesn't need to > > >> >> support > > >> >> both, just switch to the native. Or am I reading this differently? > > >> >> TVL > > > > >> >>> On Jun 9, 9:00 pm, Jeremy Moskovich <jer...@chromium.org> wrote: > > >> >>> > A couple more things: > > > > >> >>> > * I think ultimately we should support the grammar checker, but > at > > >> >>> > first > > >> >>> > just getting spellchecking to work would be great! > > >> >>> > * +1 for supporting the Cocoa gui for spellchecking paragraphs, > see > > >> >>> > the > > >> >>> > 2nd > > >> >>> > paragraph bellow for more thoughts on this. > > > > >> >>> > Matching Linux & Windows functionality is a non-goal IMHO, to > > >> >>> > reiterate > > >> >>> > we > > >> >>> > want to behave like a native Cocoa application. > > > > >> >>> > WebKit/Safari already support these features so the issue is to > get > > >> >>> > the > > >> >>> > plumbing working right in our multiprocess model (which may be > > >> >>> > non-trivial). > > >> >>> > IMHO the correct route here is to look at how this is done in > > >> >>> > WebKit > > >> >>> > and > > >> >>> > match the behavior there as much as possible, that's what I'm > doing > > >> >>> > with > > >> >>> > the > > >> >>> > keyboard events at the moment and it's proving pretty fruitful. > > > > >> >>> > It's really exciting you're working on this!! > > > > >> >>> > Best regards, > > >> >>> > Jeremy > > > > >> >>> > On Tue, Jun 9, 2009 at 5:50 PM, Jeremy Moskovich > > >> >>> > <jer...@chromium.org>wrote: > > > > >> >>> > > IMHO there is no need to maintain dual hunspell/OSX > spellchecker > > >> >>> > > backends. > > >> >>> > > There are addon OSX spellcheckers for other languages e.g. > > >> >>> > >http://www.mitzpettel.com/software/hspell.php > > >> >>> > > . Writing additional spelling servers is pretty simple so I > > >> >>> > > think > > >> >>> > > the correct approach would be: > > > > >> >>> > > 1. Getting OSX spelling/grammar checking support working well. > > > > >> >>> > > 2. If the need arises, wrapping hunspell as an Apple Spelling > > >> >>> > > service > > >> >>> > > and provide it as a separate project users can install. > > > > >> >>> > > Best regards, > > >> >>> > > Jeremy > > > > >> >>> > > On Tue, Jun 9, 2009 at 5:32 PM, Paul Wicks < > pwick...@gmail.com> > > >> >>> > > wrote: > > > > >> >>> > >> Crap, sorry to post an incomplete version of this post > earlier. > > >> >>> > >> Accidentally hit send before I finished it. Argh... > > > > >> >>> > >> Anyway, > > > > >> >>> > >> I've been looking at implementing support for the OS X > > >> >>> > >> spellchecker > > >> >>> > >> on the > > >> >>> > >> Mac build as part of my SoC project and I thought I'd run > some > > >> >>> > >> thoughts I > > >> >>> > >> had today by the list. > > > > >> >>> > >> For the basic design, both hunspell and the os x spellchecker > > >> >>> > >> need to > > >> >>> > >> be > > >> >>> > >> usable, since hunspell supports more languages than OS X > does. > > >> >>> > >> The > > >> >>> > >> public > > >> >>> > >> interface of the Spellchecker class is fairly small (mainly 2 > > >> >>> > >> methods: > > >> >>> > >> SpellCheckWord, AddWord). It seems that mapping these onto > the OS > > >> >>> > >> X > > >> >>> > >> spellchecker shouldn't be too hard. I originally thought to > do > > >> >>> > >> something > > >> >>> > >> more elaborate and create seperate spellchecker classes for > each > > >> >>> > >> platform, > > >> >>> > >> but then realized that I could do it more simply as follows: > > > > >> >>> > >> -leave the majority of spellchecker.cc as is. It works and I > > >> >>> > >> don't > > >> >>> > >> see any > > >> >>> > >> reason to mess with what works. > > >> >>> > >> -for SpellCheckWord, change the call to hunspell_->spell(...) > to > > >> >>> > >> call > > >> >>> > >> a > > >> >>> > >> (new) private method in the SpellChecker class. In this > method, > > >> >>> > >> add > > >> >>> > >> some > > >> >>> > >> code at the beginning that will check if we are on the mac > and if > > >> >>> > >> the > > >> >>> > >> built-in spellchecker supports the current language and if so > > >> >>> > >> checks > > >> >>> > >> the > > >> >>> > >> word using it, other wise using hunspell as before. This way, > we > > >> >>> > >> can > > >> >>> > >> leave > > >> >>> > >> the rest of the code alone and still use the > > >> >>> > >> SpellCheckWordIterator > > >> >>> > >> to grab > > >> >>> > >> individual words out of the string. As for getting the > > >> >>> > >> suggestions > > >> >>> > >> for a > > >> >>> > >> word, it might make sense to do things a little differently, > > >> >>> > >> since > > >> >>> > >> there is > > >> >>> > >> no need to create and manage the char** suggestions variable > to > > >> >>> > >> pass > > >> >>> > >> to > > >> >>> > >> hunspell, as NSSpellChecker can give us an > > >> >>> > >> easy-to-iterate-through > > >> >>> > >> NSArray. > > >> >>> > >> Probably just an #if defined(OS_MACOSX) would suffice here, > since > > >> >>> > >> the > > >> >>> > >> code here will be wholly different. > > >> >>> > >> -for AddWord, their probably isn't as much of a need to > abstract > > >> >>> > >> the > > >> >>> > >> hunspell specific code (it's all hunspell code), so just an > #if > > >> >>> > >> defined( > > >> >>> > >> OS_MACOSX)+language support check would suffice. > > >> >>> > >> -The other public methods all deal with language selection > and > > >> >>> > >> querying, > > >> >>> > >> which should remain the same, since the OS X spellchecker > only > > >> >>> > >> supports a > > >> >>> > >> subset of the languages supported by hunspell. (there may > need to > > >> >>> > >> be > > >> >>> > >> a > > >> >>> > >> little bit of code to translate between the codes for > supported > > >> >>> > >> languages so > > >> >>> > >> that the built-in spellchecker always gets used when it > should, > > >> >>> > >> but > > >> >>> > >> this > > >> >>> > >> should be a relatively simple matter. > > >> >>> > >> -The private method IsValidContraction could call the same > new > > >> >>> > >> private > > >> >>> > >> method as defined above. > > > > >> >>> > >> -This way, the public interface stays the same and the mac > folks > > >> >>> > >> get > > >> >>> > >> to > > >> >>> > >> use their own dictionary. > > >> >>> > >> -The newly added autocorrection code should work just the > same as > > >> >>> > >> before, > > >> >>> > >> as it relies on SpellCheckWord. > > >> >>> > >> -also, [NSApplication sharedApplication] needs to be called > > >> >>> > >> before > > >> >>> > >> the the > > >> >>> > >> built in spellchecker is used. I'm not sure of where the best > > >> >>> > >> place > > >> >>> > >> to put > > >> >>> > >> this call is. > > > > >> >>> > >> The upside to doing it this way is that it should be > relatively > > >> >>> > >> easy > > >> >>> > >> to > > >> >>> > >> modify the spellchecking code for any one platform without > > >> >>> > >> breaking > > >> >>> > >> any > > >> >>> > >> other. > > >> >>> > >> The main downside that I can see for doing it this way is > that > > >> >>> > >> for > > >> >>> > >> languages that are supported by OS X, we will be keeping a > > >> >>> > >> hunspell > > >> >>> > >> object > > >> >>> > >> around that we don't need, at least until the language > changes to > > >> >>> > >> something > > >> >>> > >> hunspell supports and os x doesn't > > > > >> >>> > >> There are a few additional features that the OS X > spellchecker > > >> >>> > >> supports > > >> >>> > >> that need some discussion. > > >> >>> > >> 1. Grammar checker: I know I've seen some talk about adding > this > > >> >>> > >> to > > >> >>> > >> chromium somewhere. The OS X spellchecker also has support > for > > >> >>> > >> checking the > > > > ... > > > > read more ยป > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
