gspell FAQ

Differences between gspell and GtkSpell

gspell has more features.

gspell is unit tested.

For the inline GtkTextView spell checker, GtkSpell checks the whole GtkTextBuffer synchronously, which can freeze the UI if the buffer contains a lot of text. On the other hand, gspell checks the buffer asynchronously. A copy of the GtkSourceRegion utility is used to keep track of the regions already spell-checked. This also permits to check only the visible regions of the GtkTextBuffer (only the text currently displayed in a GtkTextView).

Different API. gspell has more classes, while all GtkSpell public functions have the gtk_spell_checker prefix even though not all those functions belong to the GtkSpellChecker GObject class. So, in my opinion, gspell has a better API.

Why a separate library?

The non-GUI parts of gspell could be implemented in GIO, with an extension point to not hard-depend on Enchant. And the GUI parts could be implemented in GTK+.

I (SébastienWilmet) created gspell as a separate library for several reasons:

Be able to iterate on the API more freely, and have something working (and used by several apps) in less time. Now gspell-1 has a stable API, but nothing prevents me from bumping to gspell-2 to break the API, making the new major version parallel-installable. For the time being, GIO is stuck at version 2, which means that breaking the API is not possible there.

Be the maintainer. If I wanted to integrate spell-checking in GIO and GTK+, the project would have taken much more time. With a separate library, it was done in a little more than 6 months, working on and off on it (and part-time). I didn't want to be blocked on my work because of a lack of reviews.

Having the code self-contained. Having all the spell-checking-related code in one repository. The biggest *.c file contains currently 1500 lines. Mixing all the GtkTextView support of gspell into GtkTextView itself would make the code less clear and thus harder to maintain, in my opinion.