Re: Moving spellcheckers into the Gtk+ stack

[Paolo Maggi <paolo maggi polito it>]

Hi,

> 1. Use a subclass of GtkEntry -- not only does this make porting
> easier (since SexySpellEntry is implemented as such), but most of the
> entry boxes inside UIs don't need spell-checking.  There are some
> improvements I'd like to make if porting SexySpellEntry directly,
> which I'm happy to talk about with interested parties.

Suppose we have a GSpellChecker class similar to GeditSpellChecker (you can 
see it as a GObject-class wrapping EnchantDict).
What about adding to GtkEntry the following functions:

/*
 * Add a new spell checker to the list of spell checkers (multiple
 * checkers are used to support multiple languages)
 * Returns: the number of spell checker in the list
 */
gint            gtk_entry_add_spell_checker    (GtkEntry      *entry, 
                                                GSpellChecker *checker); 

/*
 * Remove a spell checker from the list
 * Returns: TRUE if the checker has been removed, FALSE otherwise
 */
gboolen         gtk_entry_remove_spell_checker (GtkEntry      *entry, 
                                                GSpellChecker *checker); 
/*
 * Returns the list of spell checkers. List must be freed with g_slist_free.
 */
GSList         *gtk_entry_get_spell_checkers   (GtkEntry      *entry);

Note that we can add a similar set of functions to GtkTextView too.

Note also that this is very similar to what we already do for
GtkEntryCompletion.

> 2. Include a standard language picker widget.  Lots of applications
> are going to want this, and it's going to become messy if people can't
> just drop in something.  This has applications beyond spell-checking
> too.  I personally feel that it's nicest to check words in the union
> of selected languages, so that users don't have to micro-manage
> settings for each UI element that they may potentially be typing in.

I agree.

> 3. Merge the backend for the spell-entry and textview spellers.
> GtkSpell3 (currently only in cvs) shares a lot of similarity with
> SexySpellEntry, and it was always my intention to merge them together.
> There's an opportunity to do some nice spell-context API for
> extending spell checking facilities into custom widgets too.

We can write a GSpellChecker class similar to GeditSpellChecker and use it
as common backend.

What about a IRC meeting among all the people interested in moving 
spell checkers into the Gtk+ stack?

Ciao,
Paolo