WeSay Development Progress

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.

One of the things that’s been bugging us for the past couple weeks has been performance. Sure it’s fast on our machines but what about our target machine. There is quite a difference there. So I was finally able to get a Linux distribution (Ubuntu 6.06) on an old Dell Latitude CP M233XT (Pentium II 233 128MB Ram). While the amount of ram is the same as our target machine, the clock of the Dell is much slower than the OLPC’s. When I ran WeSay, it was very responsive. It did take around 12 seconds to launch but once it was up, moving around was pretty much instantaneous with a slight hint of a lag occassionally. Needless to say, we are very pleased. The mono+WeSay footprint was around 48M. The system was using 20M of swap.

These have been an exciting last few days, as our prototype has got to the place where we can start getting some questions answered. Happily, our quick tests (just looking at the Windows Task Manager), show that we can load the prototype with a 32k-word Thai glossary in just a couple seconds on my laptop, using only 22 Megs of RAM. A test with only 5k words took just a meg or so less. So we effectively don’t have to care how big the user’s dictionary gets. Even scrolling through the list (which is very fast), the RAM usage doesn’t grow more than one meg, and then it drops back. Score one for db4o & Eric’s lazy TreeView. This doesn’t count the RAM used by the .net framework itself, though. On a mono install, we’ll have some overhead that we haven’t measured yet.