gspell maintenance

The gspell bug tracker is perfect again, there are only feature requests (marked as enhancements).

I’ve fixed two bugs recently, the second one was not that easy to fix:

  • One crash (a failed assertion) probably due to a bug in an underlying library.
  • A responsiveness problem when editing long lines. It turned out that the spell-checking code for GtkTextView was very slow (200 ms to re-check the long line). So I’ve written a new implementation, which is 20x faster! So with 10 ms it’s now responsive.

And I regularly do other various maintenance tasks in gspell, as can be seen in the Git repository.

gspell is now used by at least 6 applications (see the list on the wiki page), and with both GtkTextView and GtkEntry support I’m sure a lot more applications will use it in the future.

If you like the work I’m doing, the gspell fundraising is still open. Your donations encourage me to continue to take care of gspell, to make it a rock-solid library and well-maintained in the long term. Thanks!

4 thoughts on “gspell maintenance”

    1. Thanks for your comment, I’m glad to see that there are at least a few people other than me caring about gspell 🙂

      During the whole lifetime of GTK+ 3 (5 or 6 years) there were no library for spell-checking GtkEntry! There was GtkSpell for GtkTextView, but it was far from a good API and implementation.

      So even if gspell is not perfect to integrate it in gnome-builder and to implement the features that you want, I think it’s entirely possible to improve the gspell API to accommodate more needs. (And those improvements would in turn be useful for gedit and other text editors). If the API needs to be broken, we can just bump the major version and release gspell-2 (this will anyway need to be done for GTK+ 4).

Leave a Reply

Your email address will not be published. Required fields are marked *