I'm working on implementing:
http://fedoraproject.org/wiki/Releases/FeatureDictionary
in our KDE packages. This is the current situation:
* KDE 4 uses an API called Sonnet for spellchecking. Sonnet already has an
enchant backend, and it is the default recommended by upstream. There's also an
aspell backend; we will probably drop the aspell-devel BR so we lose the hard
aspell dependency, aspell can be used through enchant anyway (using
enchant-aspell, which is about to be split into a separate subpackage according
to FeatureDictionary).
* The situation in KDE 3 is more complex. We'll be stuck with several KDE 3
apps for a while to come, so I had to find a solution there too. As KDE 3 has
seen years of binary compatibility, there are 2 spellchecking implementations
in kdelibs3:
- legacy KSpell: That API uses command-line spellcheckers using the "ispell
pipe interface". It doesn't use plugins, instead, everything is handled by 2
central classes. Rewriting this code to use libraries (e.g. enchant) properly
is a lot of effort for this legacy code. Thus, I patched it to support the
hunspell command line and its "ispell pipe interface" (which required only
minor changes):
http://repo.calcforge.org/f9/kdelibs-3.5.8-kspell-hunspell.diff
The patch is preliminary, I still have to test that it works, and we also have
to make sure the defaults are set up so hunspell is used by default, at least
for new installations.
- KSpell2: This is the API KDE 4's Sonnet is derived from. It uses
spellchecking libraries and a plugin architecture. I backported Sonnet's
enchant backend plugin from kdelibs 4 SVN to KSpell2:
http://repo.calcforge.org/f9/kdelibs-3.5.8-kspell2-enchant.diff
I did a minimum amount of testing on this one, it could probably use more. And
here too, we'll want to make sure it is the default, most likely by not
shipping any other KSpell2 backend.
This comes "fresh out of the presses". I haven't added these patches to the
Rawhide packages or submitted them upstream yet.
Kevin Kofler