+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<[email protected]> 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) <[email protected]> > 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<[email protected]> >> 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<[email protected]> wrote: >> >> >> >> >> >> On Wed, Jun 10, 2009 at 2:38 PM, p_W <[email protected]> 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/31832b99aeb953d7/d722d0f183a0b35f?hl=en&lnk=gst&q=OSX+spell#d722d0f183a0b35f >> >>> >> >>> 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 <[email protected]> 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 >> >>> > <[email protected]>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 <[email protected]> >> >>> > > 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 >> >>> > >> 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 >> >>> >> >>> >> >> >> >> >> >> > >> >> >> > >> > >> > >> > -- >> > Mike Pinkerton >> > Mac Weenie >> > [email protected] >> > >> > > >> > >> >> >> > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
