Reorganizing, issues with a few Widgets

Well, it's been a few days since I've had a serious blog post. I was in Maryland for Tuesday afternoon through Thursday night (got back around midnight) for interviews with the [government]. I think things went well, and hope to hear back from them (although it's a "hurry up and wait" mentality, that may be up to a month).

As far as sugarbot goes, I got a bit done on Tuesday evening at the airport, but didn't have any time to work Wednesday or Thursday. I've made a few additions so that sugarbot now reads from an actual configuration file (located in the sugarbot.activity directory for now), and can load any arbitrary activity. From the activities that I've tested (Write, Terminal, and Browse), there may be some issues getting some of the more specialized Widgets to respond properly. I need to do some research into the AbiWord widget, for example. Although they are unique to their Activity, I would like to have support for the more common ones. Unfortunately as far as a simple demo goes, Calculate.activity is a poor candidate since it [1] requires modification to be able to check the input field and [2] stores the answers along with the output. So instead of:

click '1'

click '+'

click '1'

click 'enter'

text 'calculateAnswerField'=='2'

the required script might instead read:

text 'calculateAnswerField=='1+1\n\t2' [or however a gtk.TextBuffer stores the text internally]

I have also moved some functionality around, but it is mostly just a matter of what is initialized where. For example, the sugarbot Activity instance class needed access to the parser, which means that the parsed commands had to be passed down to the sbgui object, etc. I also spent a little bit of time on the IRC channel (#pygtk) and found out a more convenient/likely to work with other kinds of widgets method for simulating clicks and typing (via Signals). Nifty.

Currently, I do not have any ideas on how to tell sugarbot which file to read from, aside from some hard-coded value. I would greatly prefer to not use the GUI to do this, so that it would be easier to automate. A few things off the top of my head that might work...

• A script file that actually contains multiple scripts. With each subsequent execution, the next 'script' is run. sugarbot keeps track of where it needs to read from next with some other file, and resets that data once it reaches the end.
• Use the network to connect to some separate 'server' application that tells sugarbot what to do. This other application would have unlimited flexibility, since it is not bounded by the Sugar environment.

As far as automating the process of starting sugarbot in the first place, that's another problem to tackle. I need to find some way to hook into the PyGTK calls of the Sugar process, in a similar manner that I've used to automate activities. Again, I'd prefer to find a way to do this without modifying any code in the Sugarbot base.