Re: Moving spellcheckers into the Gtk+ stack

["Dominic Lachowicz" <domlachowicz gmail com>]

Hi Behdad,

>   - Move Enchant into glib as a new module called gspell.  Enchant is a
> small client-side library that loads modules that interface with
> spell-checking backends, like aspell, ispell, MySpell, etc.  It's
> written by Dom, uses glib, and KDE recently forked it and called it
> kspell2 or something.  So, I don't think it has a lot more opportunities
> as a fd.o project, and all its users are using the GNOME stack already.
> Other projects (OO.o, Mozilla), prefer to interface directly with
> backends or reinvent their own wrapper.  So, by moving Enchant to glib,
> we bring spell-checking to the entire GNOME stack for free.  This is
> quite in par with the gregex and gvfs efforts going on.  Dom is pretty
> positive about this.

For reference, here's Enchant's website:
http://www.abisource.com/projects/enchant/

This is great, and I've been hoping for something like this for years now.

For what glib version are we proposing to include this? There are some
cleanups that I'd like to do before we move it up into a "gspell"
library, but I had previously avoided in hopes of broader adoption by
the KDE folks. That never happened, but I'm quite happy to have it
included as part of the GNOME platform instead.

I'd like to change the following when moving this up into gspell:

*) Clean up the deprecated APIs
*) Re-tool the library to use GErrors
*) Translatable strings
*) Rename functions to live in the "gspell" namespace
*) Get some API review from ya'll
*) Use XDG-DATADIRS when looking up dictionaries, plugins, and etc.
*) Continue to provide an "enchant" library that wraps the new gspell
component, for backward's compatibility? Or do we just leave Enchant
1.next as the last release of enchant proper?

We'd want this to be optional built and have its own .pc file, like gregex.

Other people's suggestions and critiques are of course welcomed.

>   - Add properties and Gtk settings for turning on/off spell-checking
> globally, setting default languages, etc.  Possibly adding context menu
> entries too.

Yeah. We can probably do interesting things keying off of Pango's
"language" property.

>   - Develop a simple tool for control-center to adjust above settings.

Is this strictly necessary? Or would it be better to have it default
to g_getlocale()?

Best,
Dom
--
Counting bodies like sheep to the rhythm of the war drums.