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 grammar of a string (only in 10.5+), so that is something to keep in mind when that stage is reached. 2. Spelling Panel: The OS X spellchecker has support for a "Spelling Panel". Similar to spellchecking in most word processors, this provides a seperate GUI Panel that allows for checking a whole paragraph in one go. The main problems here are that this is functionality that is in no way matched by the Windows or Linux Builds. Additionally, it would require some way of identifying the source of each word, since the spelling panel allows for the creation of a list of ignored words, which are unique to a document. In the case of chromium, a document would correspond to a given textfield, most likely. The NSSpellChecker API provides a function (uniqueSpellDocumentTag) to generate tags for this purpose, but a way would have to be found to generate and match these tags up, which could be complicated (although I admit that I've not spent a lot of time looking at the code that would need to be altered to make this aspect of the spelling panel function). Any thoughts would be great. Thanks, -Paul Wicks --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
