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.

Today’s main task was to get FieldWorks Language Explorer to build on my machine, so that I can work on adding the ability for users to import and export the forth-coming xml dictionary interchange format files. We need this to make it really easy to exchange FW data with WeSay users.

Anyhow, that’s looking like take a couple days of effort to actually get it to build. So, in between inevitable build failures, I started hooking up Spring.Net. We plan to use this for a couple different framework services. The part I got working today was simple object creation/dependency injection.

We want advisers to be able to configure many aspects of WeSay. They need to be able to, for example, just display those tabs which facilitate the tasks that a given user is ready to take on. We also want people to be able to program their own extensions to WeSay, which may come in the form of new tab controls. So the tabs can’t be hardcoded… they must come from the configuration file. Now, eventually, we will need some nice GUI for building these configuration files. But for now, we’re just going to use the raw Spring XML.

I got to the point that Spring is now configuring each of the tabs in WeSay, so that part of WeSay is now configurable. Maybe tomorrow I’ll blog about how this works.