A nice feature of Mac OS X is that every text edit field has spell checking built in. Getting this for QTextEdit is possible with Qt today but is a bit involved since you have to write a few lines of code and interact with NSSpellChecker using Objective-C. So, to save people from having to learn a strange new language I’ve created the QtMacSpellCheckingTextEdit class:

The code is available here under the GPL license, and it will also be a part of the next Qt Solutions release with a commercial license. The next step will probably be to make this cross-platform by integrating with other spell checking engines such as Aspell and Ispell.
22 Responses to “Spellchecking for QTextEdit on Mac OS X”
Awesome! An Aspell version of this would be great. I’ve been thinking of rolling my own for QGraphicsTextItem, but if there was a nice example to work from….. ![]()
The menu could use some spell checking … “serach in Google”
Looks great apart from that!
Thank you so much for this. I have been wanting this for years and never knew which way to go.
I am a Qt Solutions subscriber and look forward to the day we can use it in our product.
Trolls Rule!
FYI: I am using QT 4.3.1 on OSX 10.4.1 and I used the easy installer not a regular QT compile and I got errors.
So I had to change the .pro file to look like this:
DEPENDPATH += ../src/
INCLUDEPATH += ../src/
(I took out the periods before ../)
works now. founds my typos and everything.
Might be a good idea to use something a bit more abstract than ispell,
check out Enchant:
http://www.abisource.com/projects/enchant/
Why not go for something like Sonnet immediately, which also offers grammar check & automatic language detection? It’s gonna be in KDE 4, so you guys can evaluate how it works, and then improve upon that when it becomes part of Qt…
BTW that security check thing really sucks… had to try like 10 times… ![]()
“Spelling” needs to be capitalized in “Learn Spelling” and “Ignore Spelling” as well.
I’m curious why TrollTech treats commercial developers as second class citizens for extras like these. To my knowledge, we’re the main source of the funds that build of Qt. So why is the code not released immediately available?
I’m not asking for preferential treatment here, but equal treatment would be nice.
As far as I know, you’re also getting some stuff in Qt Solutions which we Free Software folks never get, so the inconsistency goes both ways.
And by the way, you should be using the cross-platform KDE 4 libs rather than this OS-specific hack anyway. ![]()
Steven:
I think it’s mostly a quality issue. By putting a commercial license on it and providing it to our customers we state that the code has reached a certain quality level and is supported. At this point I think Morten is not done with it yet, and therefore just provide it as-is. Then it’s easier to just GPL it. (And no - I’m not saying most GPL code is crap here :D)
I guess what you are aksing for is to get your hands on it and be allowed to use it in a commercial product no-matter what state it’s in.
All of the Extras I’ve tried so far have been low quality, so I’m not sure I buy that argument. So I’d love to try it (myself, not in a product) what’s there now before my expectation builds to levels the code can’t possibly meet.
Thanks for making this available! It would be great if Trolltech offered other things like this to make it easy to access generic apple specific api features without having to incorporate objective c code into Qt applications for the mac. This is a good example of something every apple customer would expect in every mac application, so it’s great that you have provided a painless way to access it. Easy access to apple coreimage/corevideo without having to use objective c might be another thing to consider for Qt Solutions.
I think John Dalton above has it right. Going forward, I’d love to see this as simply a property on both the QTextEdit and QLineEdit controls.
That might well happen. Labs content is early research, it’s not for production use. Our only alternative to releasing early research unsupported, through the GPL, is to not release it at all. As Morten stated, this code will soon be available through Qt Solutions, with a commercial license. But it’s in our common interest that pre-alpha state code does not end up in production. This is not about extra privilege for the Open Source community only, it’s about letting anyone, customers included, be able to try the code at all, before it eventually ends up as part of our product line. ![]()
As suggested before, why not pick up Sonnet like what happened with Phonon?
I agree. More OS X centric modules would be a great Solutions add on.
We can’t use Sonnet inside QtGui, since Sonnet depends on QtGui (chicken-egg). I’ll try to hypnotize Morten into making spell checking plugin based, so we won’t have trouble with dependencies.
Sonnet already supplies a syntax highlighter for QTextEdit (sonnet/highlighter.h), adding the suggestion list to QTextEdit will thankfully be a no-brainer ![]()
Andreas: I thought commercial customers couldn’t use GPL components. Do you mean it’s okay to install GPL components in Qt/Commercial for prototypes and testing? Wouldn’t that require the solutions be dual licensed instead of just GPLed (or at least have an exception for commercial customers who’ve purchased the Solutions)?
Thanks for the feedback, I’ll make sure that the menu is properly spell checked when we release it as a solution.
Using Sonnet from a pure Qt application seems tricky, but if it can be done it is definitively the way to go on the KDE platform. As I understand it, Trolltech can use Phonon since is does not have any dependencies to the rest of KDE, something that I don’t think is true for Sonnet.
Steven: The GPL only covers distribution, not use. You are free to install and test GPL components with Qt/Commercial. Qt Solutions are licensed under a commercial license (and generally not under the GPL).
Wouldn’t it be better to use setExtraSelections? The syntax highlighter will modify the underline style which interferes with rich text editing.
Thanks Morten. The widest I’d be distributing the resulting executable is to a couple people within the company to get their opinions. Technically, everyone would have access to the source, and is covered under NDAs, etc, so I’m all good.