WeSay Development Progress

Thanks to Cathy, we now have a revamped skin on our wiki. We also have acquired wesay.org so update your bookmarks.

I have been working on two areas of WeSay. The first is our data access layer. Db4o provides a read only IList when queried. In the prototype, I had wrapped that result and provided our own read-write IList that automatically kept the database up to date. With John’s databinding work, we decided to provide a IBindingList interface over db4o. I spent quite a bit of work creating tests for the various interfaces: IBindingList tests, IList tests, ICollection tests, IEnumerable tests. I had an implementation working with tests when we hit performance issues with filters and John found Marek Istvanek’s work on providing a binding list over db4o. I chose to only use his db4oList class and implemented my own Db4oBindingList since we won’t be needing the paging and didn’t want to take on the associated risk. I had to modify the Db4oList class so that it would pass my previous tests.

Another big change to the Db4oList class had to do with unregistering the PropertyChanged event on classes which implement INotifyPropertyChanged. A number of people have blogged about the “lapsed listener” problem which causes objects to remain in memory due to the event source retaining a reference to the listener after the listeners go out of scope.

The solution to this tricky issue is to either use weak delegates or require a call to dispose before the listener goes out of scope. Wesner Moise claims that implementing weak delegates is a difficult proposition with a number of casualties (Joe Duffy and Ian Griffiths) to date. I found three implementations that still purport to be correct: Greg Schechter (he also provides the best overview of the problem space), Xavier Musy, and John Stewien. We finally decided the best way to handle this was to remove the listener from the event source when dispose is called.

The other area is in moving our proof of concept lazy GTK nodestore to production standards. In the process I came across this blog entitled DataBinding an IList as DataSource for the Gtk.TreeView. This obviously peeked my interest. At first, I adapted his code to use an IList but when I tried to load the assembly, I discovered that templated classes cannot contain references to external methods, which makes sense so I’m back to using an IList. This is still a work in progress for me too, but you can check out what I’ve done in our subversion repository.

After two discouraging days of trying to get Mono to work on the OLPC image, I have finally figured out why I was up against such a brick wall. The first problem I had was that the Mono installer for linux only provides bindings for GTK+2.4 and we have been using GTK+2.8. After unsuccessfully trying to use a machine.config file to tell mono that it can use GTK+2.4 in place of 2.8 (which I don’t know that it would have worked but I couldn’t get it to recognize that even), I finally decided to just copy over the 2.8 bindings from my ubuntu install.

Now I thought it would be easy from that but after awhile of getting all that hooked up, I determined that the gtk version on the OLPC must not be old enough and I copied over the ubuntu libs, only to find when I was going to copy them that the OLPC distribution is using GTK+2.10.

Apparently Fedora has a version of Mono that will work with GTK+2.10, so I have now decided I’m either going to have to build my own image Mono as a part of it or wait until Mono supports GTK+2.10.
On a whim, I took up Daniel Olivera’s offer to access his OLPC motherboard and ran some performance benchmarks to see how this compares to our test machine. The benchmarks seem to indicate that our test machine is about 75% as fast as the OLPC. You can read more details about it here. This puts my previous blog about the performance of WeSay on our test machine into better perspective.

Further testing on the memory usage seems to indicate the WeSay+Mono footprint on Linux is not 49MB as we previously thought but 19MB which is more like what we had found on Windows as well.

Thanks to Martin, I finally was able to get pango to use the graphite engine. I had to install the debs that he gave me (as far as I know they haven’t made it to a universe repository yet). My attempt to download the source, compile and install it led to frustration, first because pango wasn’t picking it up (this I found out was due to the lack of a ModuleFiles entry in my .pangorc file. But then all I got was boxes. That’s when I installed from the debs and everything works as you can see in the screenshots I uploaded. Notice the Pig-Latin-ization of the labels. One of our goals is to make the interface itself easily localizable which needs to include the ability to handle complex scripts which require graphite. Currently, this is only supported on Linux since the pango-graphite module for Windows hasn’t been written yet. Hopefully I’ll have that done in another month (we don’t consider this high priority at this time so I’m only doing that on the side).

The other thing I’ve been working on was integrating the word list view with the detail view (see screenshot). The current path we are taking is for each tab to have a filter associated with it that will provide the set of words that need to be addressed for the task at hand. So if the task at hand is assigning glosses to each of the words that have been entered, the filter may display only those words which do not have a gloss. This also means that each tab saves its own state (current entry) so when you switch to another tab and come back, you are where you left off.