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