sugarbot's aim is to provide testing and automation facilities for the OLPC Project's Sugar GUI. The project must first identify and evaluate possible implementation options, and then implement the best choice. Although it has a Sugar focus, sugarbot should be easily extensible to other Python-based GUI's.

Saturday, May 17, 2008


So I've figured out how to intercept gtk.Event's, and then match them to various gtk.Window's or gtk.Widget's.  Easy peasy.  What I would like to be able to do, is given a gtk.Window, query it for its child widgets.  Unfortunately, that approach doesn't seem like it would be a good idea, given the big variety of ways to pack widgets into a window.  I might have to come up with a case for each and every type of widget-packing class.  Not cool.

What I think will work better is intercepting the gdk.MAP Events, and trying to relate a given Widget to its parent Window at that point in time.  I don't know how well this will work if there are pop-up dialogs or tool windows, or things like that.  I also don't know how well that will work with the Sugar interface, given that everything is effectively a big window.

What I think would be a good way to see how the Events get thrown around when running Sugar.  I think that with the class I've got, I can turn a few things off so that it just prints out all of the Events that are generated.  From there, I can find out which ones I care about, and which ones I don't.  That should give me a good idea of the kind of functionality that will be needed (hopefully).  That's all assuming that Sugar uses PyGTK (which I am 99% sure it does), and that when it launches activities, it keeps them running in the same process (which I am about 50% sure it does).  I'll know later tonight, I guess.

No comments: