"The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents." -Nathaniel Borenstein

Welcome to my development blog for Google Summer of Code '08! I was one of the students that lucked out and was selected by the SIP Communicator to make multiple contributions including:

Adieu Before Closing Curtains

Quite a bit has happened in the weeks since the last entry. Yana and I decided to drop the history search project in favor of focusing on the spell checker. This has included finalizing its integration with the trunk and several changes including:

• Adding a toolbar button to enable/disable spell checker
• Using a ghostly texture for the flags of locales that aren't installed
• Moving configuration to defaults.properties
• Providing the ability to swap locales while composing messages. Originally this was through a combo-box on the toolbar but it's now through a submenu.
• The JMySpell developer provided a fix for the bug afflicting some locales, allowing us to include:
  Czech (Czech Republic), Galician (Spain), Hebrew (Israel), Italian (Italy), Latvian (Latvia), and Nepali (Nepal)
  bringing the number of supported locales to 72.
• Resolving a bug concerned a boundary condition when deleting characters. It was a bit of a mystery since it frequently occurred on Yana's system but I was never able to reproduce it. After several emails back and forth it looks like it's inconsistent due to a bug in the Mac Java implementation.

Though this is the last entry for gsoc '08 I've enjoyed my time with this development community and plan to continue with the project as able. The spell checker has yet to be committed and there's an on-going discussion about providing a better means of updating dictionaries. Once this and the keybindings patch have been resolved I'll finally start on the history search.

Last Hurrah for Keybindings?

After twelve days of tweaking they keybindings service I've finished the suggested modifications which included:

• Adding a 'Set Default' button
• Adding alternative binding support (which included unpacking and removing the KeybindingUtil jar)
• Adding bindings for fonts
• Merging the keybindingchoosr plugin into the keybindings service implementation
• Using services to store default and custom bindings as plain text
• Writing a revised how-to for adding new bindings
• A few bug fixes...

Merging the keybindingchooser caused a chicken-and-egg issue with the Swing look & feel initialization that was resolved by merging both with the UI service. This isn't a perfect solution in that plugins can't access it as a normal service and it's bad for modularity. For now the service's handle is provided via the UIService. Perhaps we'll figure out a better solution later but for now this isn't a terribly big whoop.

Still Tinkering...

'I thought it was done' you say? Bah, I wouldn't be a developer if there wasn't some feature creep! Contrary to convention, though, the inclusion of JOrtho should simplify the code rather than complicate due to the introduction of an interface abstraction for the spell checkers.

I just got JOrtho working in a standalone spell checker, which wasn't quite as simple as it sounds. In an overzealous effort to hide implementation details the API only provides functionality at the UI level. Unfortunately this limits our control and prevents it from working within the plugin. Hence the source needed some tweaking to provide access to the underlying dictionaries. Once this was done it provided a nice, basic interface similar to JMySpell (and was trivial to introduce as a replacement).

In my opinion it was a mistake on the part of JOrtho's developers to hide the basic spell checking API but I'm happy they did. Though FOSS advocates often tout customization as a major benefit of having the source code this was my first time to take advantage of it. Viva la libre code!

The major benefit of using JOrtho is that its dictionaries are generated via Wiktionary. In theory this takes advantage of the wisdom of crowds in contrast to the conventional design by committee, better reflecting language as both living and evolving. Unfortunately some of these benefits are lost in that the API doesn't include the code for generating the dictionaries. Hence this lacks recent additions and the spell checker's dependent on the developers providing periodic updates. Still, this seems like an interesting method of generating word lists and certainly worth including as an alternative spell checker. In other news:

• The svn repository has been fixed
• Another dozen languages are now available via JMySpell after being repackaged as zip archives
• The other problematic dictionaries seem to be failing due to an UnsupportedEncodingException when being read in. I've shot the JMySpell developer an email to see if he has any ideas.

Spell Checker Finished!

Hazaa! The main features of the spell checker are now done, including on-demand retrieval of non-English dictionaries and a management dialog for custom word lists (ie, the words users add). The former has the various dictionary repositories defined in an xml file, which are cached with the user's preferences when requested. Currently this supports 54 locales, and an additional 35 are available but evidently incompatible with the spell checker. I'm guessing that for a dozen this is simply an issue with recognizing tarballs (which would be easy to fix). For the zip archives, though, I haven't a clue what's wrong. It's possible this is an issue with a formatting change being made with Open Office (the source of the dictionaries).

Subversion failed rather spetacularly, corrupting this project's repository and a bit of my faith in version control systems. The problem appears localized to the image and language resources and until it's fixed they can be downloaded here. The undo and alternative spell checker issues still remain and I'm planning to look into using JOrtho next.

Basic Spell Checker Integrated

My svn repository now has a functional spell checker that corrects as you go. It took several changes to the gui service to accommodate the plugin, mostly changes to the Chat interface and additional listeners for aspects of the UI the plugin's interested in. Remaining issues include the following:

1. Bug- First undo of a correction clears text

   Corrections are in two parts, removal of the wrong word and inserting the new one. Hence undo operations first clear the correction then the second return the misspelling (confusing for the user and revealing implementation details). To try to fix this I'm now using the setMessage(String) method of the Chat interface but this appears to have a similar bug in that undoing clears all the text, then the second undo returns the original message. To fix this it looks like the ChatPanel needs access to the trimEdits method of the UndoManager which is, unfortunately, protected. I'll look into this some more later but for now I'm stuck...

2. Default dictionary location?

   I'm not sure where to put the default (English) dictionary. I tried 'resources/languages' but after a couple hours of hair pulling I found out the ant script only copies '.properties' files to the classes directory. Hence for now I've made a 'resources/misc' branch.

3. Non-English language support

   We're using JMySpell which utilizes OpenOffice dictionaries, meaning that they're small and available in numerous languages. I'm currently planning to have the plugin's form check with an on-line repository for available languages and download the resources on demand.

4. Utilize JMySpell support for custom dictionaries (ie, ignoring misspellings)

   Compared to adding multi-language support this should be simple and is the next thing I'll tackle. The spell checker's form needs an interface for managing the user specific dictionary. The right click menu also needs an option for adding the word.

5. How to test?

   Again, compared to the keybinding chooser I'm much less confident about the stability of this plugin. Occasionally I stumble upon a corner case that I'd forgotten to account for, and unfortunately UI components don't lend themselves well to unit tests so I'm not sure how best to handle this...

6. Alternative spell checkers

   The last thing I'll do is look into supporting JOrtho as an alternative spell checker. The best case scenario would be to have spell checkers hidden from the plugin by an interface so they're interchangeable (though I'm not sure yet if this is feasible).

Early Spelling Component

After a break to work on a model for my research project I'm back to coding, now working on the spell checker component. While the discussion on the dev list leaned toward using HTML for rich text formatting this is a very expensive solution, both in terms of rendering and stripping the tags to access the text. Instead I'm using the JTextPane (a subclass of the JEditorPane) which is designed to handle font attributes.

Checking a word's spelling is both a fairly sizable and time critical operation (users would be understandably upset if the spell checker noticed mistakes after a message was sent). To work on this I've written a demo class that exemplifies what we want to do except that its checkWord(String) function is currently making an arbitrary choice (checking if words contain "foo") - of course it's trivial to replace this later with a call to the spell checker API.

The DocumentListener that watches for changes only checks words around the caret. In addition, in the common case of adding text to the end it holds off on checking the last word until the word ends or the caret moves away. This still has the following issues:

• Users expect an intermittent underline (often colored) to indicate misspellings. I've found some promising forum posts discussing this so it's the next thing I'll tackle.
• Coming up with all the possible use cases for text modifications is a bit tricky. I'm fairly confident in the current code but I'm at a loss for how to test it.
• Currently this breaks up words by looking for non-letter characters. Unfortunately this means that it breaks up contractions (for instance "can't" into "can" and "t"). However, if I include single quotes then it would be problematic when they're not part of the surrounding words. There may be issues with non-letters being parts of words in other languages as well...

Getting Close...

After a week of work I'm on the verge of finishing the keybinding chooser integration. It took quite a bit longer than I'd hoped due to my stubborn insistence on learning things the hard way rather than utilizing the pretty how-to documentation provided on the site. Cest la vi. The addition consists of two components:

1. Keybinding Persistence - A new service provides keybindings to the UI via the GuiActivator. Bindings are distributed within an Observable wrapper that notifies attached Observers when the bindings change (ie, the wrapper's 'setBindings' method changes the contents). This allows the UI components that are using the bindings to update themselves when changes are made. I'm planning on writing a how-to on adding new binding sets once I clear up the remaining issues.

   The implementation of the service also transparently handles persistence. Bindings are stored in two locations- default bindings are held in resources package and customized bindings are stored with the user's configurations. When the service is first started it loads the default bindings and overwrites any duplicates it can load from the custom bindings. Whenever the bindings differ from the custom version they're saved. This portion of the chooser integration is all done and seems to be working well.

2. Keybinding Chooser - The UI component that handles the customization of the keybindings is implemented as a plugin for a couple reasons (not the least of which was a rather unpleasant chicken-and-egg issue with the UI Service). This tacks on a ConfigurationForm to the settings window, providing all the keybinding sets used in the SIP Communicator in its various tabs. This still has a few issues, most importantly that the detection of arbitrary keybindings requires the use of a KeyListener which is incredibly picky about focus. Since the chooser apparently doesn't have access to the frame it's in I'm not quite sure how to resolve this. A simple solution would be to configure bindings via dialog popups, but aesthetically I really like the current layout of the chooser...

Hello World!

Welcome to my first stab at a blog! As mentioned above I'll be making three contributions to the Sip Communicator this summer. The first is the integration of the KeybindingUtil project to provide a centralized listing of keybindings and give the user the ability to configure them. However, it's currently the middle of 'dead week' (the week before finals) so work will be rather slim as classes and research wraps up.

Next for a belated introduction. I'm Damian, a Masters student currently attending WSU and researching simulation development using FPS game engines. The vast majority of my development experience is with Java, most recently in writing utilities for high performance interlaced hexagonal boards (rotation, distance, collisions, display, etc) for my Noc Norade project. I've worked a fair bit with Swing, JOGL (OpenGL Java bindings), Python, and PHP.

A little while ago I started getting the itch to become involved with a large scale Open Source project and begin doing work that might have meaning to others (something I've never had in academia). IP communication stuck me as an especially interesting field since it included the mythical convergence of multiple modes of communication into general purpose devices (much like MythTV for media). About a year ago I looked into joining Gaim (it wasn't renamed to Pidgin yet) but all my background is in Java rather than C/C++, providing an extra barrier to the already intimidating prospect of joining a large project.

I was thrilled when I stumbled the SIP Communicator since it provides everything I was looking for in an introduction to Open Source community, namely a communication framework like Pidgin but with the convergence of multiple modes of communication in Java. I'm ecstatic about being selected and looking forward to starting!