GTK+: Adding support for spellcheckers into the GTK+/Glib stack
===============================================================
I would like to add support for spellcheckers into the GTK+/Glib stack [1].
There has already been a couple of aborted attempts at this --
gspell [2] and gtkspellcheck [3]. Closely related to this is Apple's
NSSpellServer service [4] and NSSpellChecker [5] client API for Mac OS X.
Each of those three approaches have their upsides and downsides.
GSpell proposes a GObject-based API to replace Enchant and suggests ways to
make use of it in GTK+ [6]. It uses a GSpellChecker representing one language,
which is then meant to be added to those widgets that want to support
spellchecking. More than one GSpellChecker can be added to a widget if
multiple languages are to be used. However it does not appear to be addressing
the problem of tokenizing a body of text into individual words. Leaving this
to the widgets might duplicate the tokenizing code unless we write a separate
tokenizing class that can be used outside GSpellChecker. There are no concrete
answers because the support for GSpell was never added to GTK+ itself. Also
there is no way to retrofit spellchecking into widgets that were not designed
to support it.
Gtkspellcheck is in many ways the exact opposite of GSpell. It does not try to
replace Enchant with a GObjectified API. Rather it makes use of Enchant to add
spellchecking to a bunch of GTK+ widgets. It does so by implementing the
SpellCheckClient interface and creating an instance for each widget. Each
implementation of SpellCheckClient knows how to listen for the changes in the
text and spellcheck it. Good thing is that one can retrofit spellchecking into
widgets by writing a new implementation of SpellCheckClient. Moreover it
does the tokenizing of text into words itself and does not put that burden on
the widgets.
Unlike the first two, Apple's uses an out-of-process solution by doing the
actual checking in a separate NSSpellServer service. The NSSpellChecker is
just a client library to use that service. The application does not need to
tokenize the text into words.
I would like to propose something like this:
- In Glib:
+ Use GSpell-like GSpellCheckers to encapsulate the functionality provided
that is currently provided by Enchant.
+ In addition to each language's dictionary, support personal word lists for
each user, and ignore list for each instance of a GSpellChecker.
+ Since a widget might want to have spellchecking for multiple languages
provide some sort of a tokenizer that can be shared by the GSpellCheckers.
+ The actual spellchecking engine can be hidden behind a DBus interface or
GIOExtensionPoint. Something like an Enchant daemon.
- In GTK+:
+ Add the add_spell_checker, remove_spell_checker and list_spell_checkers
methods to an interface (GtkEditable ?) and have all widgets that want to
support spellchecking implement them.
- Desktop wide:
+ If time permits, provide a way to configure spellchecking across the
desktop. eg., which languages to check for, which engines to be preferred
for which language, etc..
How does it benefit GNOME and its community?
--------------------------------------------
Spellchecking in GNOME is currently done by interfacing with other libraries
like Enchant which typically provide an abstract interface (or broker) over
the various spellchecking engines that are out there -- aspell, hunspell,
voikko, etc.. Since the widgets provided by GTK+ do not provide any
spellchecking facilities by themselves, people have come with the separate
libraries which add spellchecking to stock GTK+ widgets. GtkSpell [7] and
libsexy [8] are two such cases.
However, these libraries provide spellchecking enabled versions of only some
of the GTK+ widgets that might require spell checking. eg., GtkSpell
"attaches" a spellchecker to a GtkTextView and libsexy provides a spellchecking
enabled version of GtkEntry, but none of them cover an editable
GtkCellRendererText. Moreover, being two different libraries their APIs differ
from one another and they end up duplicating a lot of code. eg., the UI bits
to configure the spellcheckers.
By having a GObjectified equivalent of Enchant, we reap the benefits of
GObject Introspection leading to an interface that is more easily accessible
from different programming languages, and one that can be configured from one
central point across the whole desktop. (Python bindings for Enchant exist but
they do not use instrospection.) This GObjectified interface to the
spellchecking engines can then be used to provide a uniform way to add
spellchecking support to GTK+ widgets.
What components/modules will it touch/change or create?
-------------------------------------------------------
Mainly gtk+ and glib.
Since libglib-2.0 can not depend on GObject, the GObjectified client library
will have to reside somewhere else. GIO is one possibility.
As far as GTK+ is concerned it will affect most of the classes that deal with
editable alphanumeric text. From the outset GtkEntry and GtkTextView are most
likely to be touched. Some more classes that deal with text stored in
GtkTreeModel stores (GtkTextView or GtkCellRendererText ?) will be affected.
Why you'd like to complete this particular project?
---------------------------------------------------
Although I have been using GTK+ and Glib for a few years now, I have never had
a chance to hack the libraries themselves. On top of that this idea has been
floated and explored at various points in the past, and it helps to push
forward the general trend of moving away from small third party libraries
towards a more consolidated GTK+/Glib.
How do you plan to achieve completion of your project?
------------------------------------------------------
Apr 25 - May 08: Design the Glib level API and the GTK+ level API.
May 09 - May 22: Take some initial implementation decisions -- whether to run
the actual spellchecking engines (ie. Aspell, Hunspell,
Voikko, etc.) out of process or in process, whether to use
GIOExtensionPoints, etc..
May 23 - Jun 05: A rough implementation of the Glib API and with a backend to
one spellchecking engine.
Jun 06 - Jun 19: A rough implementation of the GTK+ API for a particular
widget.
Jun 20 - Jul 26: Rinse and repeat. Polish the Glib API a bit. Personal word
lists, ignore words, better multilingual support should start
to appear.
Jun 27 - Jul 03: Rinse and repeat. Polish the GTK+ API a bit. UI elements to
add/remove words from personal word lists, ignore words,
language selection, etc. should start to appear.
Jul 04 - Jul 17: Buffer to accomodate unforeseen developments in the earlier
weeks.
Jul 18 - Jul 31: Add spellchecking support in a GNOME application using the
work done so far. This is something that can be demonstrated
at GUADEC.
Aug 01 - Aug 14: Write another backend to a spellchecking engine. Extend the
GTK+ work to all other relevant widgets.
Aug 15 - Aug 21: Buffer to accomodate unforeseen developments in the earlier
weeks, bug fixes, etc..
Why do you think you are be the best person to work on this project?
--------------------------------------------------------------------
I have been contributing to free software projects on and off in my free time,
and am familiar with the GNOME stack and its development methodologies. I am
proud of my ability to teach myself new things, which includes, but is not
limited to, the ability to read and understand unknown codebases. I believe
that this gives me a certain advantage when it comes to working on this
project.
What are your past experiences (if any) with the open source world?
-------------------------------------------------------------------
A list of all my free software contributions can be found at:
https://www.ohloh.net/accounts/debarshiray/positions
I participated in Google Summer of Code in 2007 as a student under the Fedora
Project.
Why are you interested in improving GNOME?
------------------------------------------
This is what I use daily on my computers. Hence a better GNOME amounts to a
better computing experience for me.
----
[1] http://live.gnome.org/SummerOfCode2011/Ideas#Developer
[2] http://blog.barisione.org/2006-12/gspell/
[3] http://taschenorakel.de/mathias/2007/08/28/spell-checking-masses/
[4] http://ur1.ca/3sp23
[5] http://ur1.ca/3sp36
[6] http://ur1.ca/3sp8s
[7] http://gtkspell.sourceforge.net/
[8] http://www.chipx86.com/w/index.php/Libsexy