Spell Checking in KDE4 (KSpell2)

[heiko.evermann at gmx.de]

HI Zack,
> No, not really. There was a number of reasons why I haven't ported the
> rest of the apps in KDE to KSpell2. In no particular order it was:
Which ones are already ported?

> - lack of time,
If you provide us with a description about what has to be done, you might find 
others who are willing to help.

> - general apathy of people towards spellchecking,
I think so too. There is a number of things I have been wondering about, since 
we started implementing aspell for Low Saxon. The most important thing is 
that a text editor window will flag all words red where aspell has a 
suggestion. If however aspell only says the word is wrong and does not have a 
suggestion, then the word is not red. You only get them when you go through 
the spell checker dialog window. For spell checking technical texts like KDE 
documentation, this is not helpful. There is a number of technical terms that 
we do not want to add into our dictionary, and when we are proofreading our 
translation using aspell, we get these words popped up again and again. I 
would prefer to see those words in red, have a look at a phrase in KBabel and 
then judge by myself, whether or not I want to use the suggestion dialog. 
This however is not pssible.
> - lack of decision on my part as to whether I'd want to be using Enchant
> in the future. I talked a little bit to Dom about this but we never
> went ahead and coded anything. But basically the requirement on my part
> is very simple and is "Enchant can't be linking to Glib when running
> from KDE apps". From what I remember it was using only the GModule and
> codecs from Glib so I guess we could write small wrapper classes like
> ETextCodec and EModule that would be implemented both with Qt/KDE and
> Glib/GNOME specific functions and the right implementation would be
> a ./configure option.
How much work would that be?
> - people being resistant to switch because there's no documentation that
> the Ispell plugin uses Enchant ispell dictionaries and as a result
> sending bug reports about ispell plugin not working,
Why not call the modules "aspell, ispell and enchant", so that the user can 
choose.
> - stupid link dependencies - kdeui is compiled before kspell2, so
> classes classes in kdeui can't be using kspell2. And I'm not sure who
> was arguing about that but initially at least I wanted to have kspell2
> split into kspell2core which are all the non-gui classes and kspell2ui
> which were all the ui classes. I wanted the kspell2ui classess just be
> a part of kdeui (removing kspell2ui completely) and having kspell2core
> compiled before kdeui.
I think this could be sorted out. 

I would really like to see the change done, so that further development of 
KSpell is possible. I remember that some months ago we talked about some 
problems with aspell 0.6 and you said that you were unwilling to further 
change an outdated implementation. I can fully agree to that and I programmed 
a workaround by myself and checked it in. 

I think it is time to start the transition. For KDE 4 quite a number of things 
will change that break binary compatibility with KDE 3. I think that quite a 
lot of time will pass until we get such a chance again.

Kind regards,

Heiko Evermann