Google Summer of Code project, sugarbot

[Tomeu Vizoso]

Hi Zach,

sorry about my slow responses.

On Tue, May 20, 2008 at 7:04 PM, Zach Riggle <zachriggle at gmail.com> wrote:
>
> The approach that I found works with zero-to-minimal modification of
> the target applications is the same employed by kiwi.ui.test of the
> Kiwi project (http://www.async.com.br/projects/kiwi/).  The majority
> of the functionality stems from a call to gtk.gdk.event_handler_set to
> intercept all GTK Events (gtk.Event).  This allows me to build a very
> accurate picture of how a given application is laid out, through the
> various gdk.MAP (and related) Events.  Additionally, since I am doing
> a great deal of work with GTK Events, I will already have a great deal
> of infrastructure in place to deal with events, and can use them to
> drive the GUI automation.  I find that this method is very
> straightforward and non-intrusive, and allows me to see /everything/
> that goes on inside GTK.

Sounds good.

> However, the limitation of this method should be readily apparent: It
> only works when the target code is executing in the same process as my
> code.  In order to handle this for normal PyGTK apps, a simple call to
> exec() would suffice in getting the code to execute in the same process.
>
> For actually working with OLPC Activities, it was suggested to port
> what code I had into a Sugar Activity (not a difficult task,
> thankfully), and attempt to "call" other Activities from there, for
> example:
>
> class sugarbot(activity.Activity):
>        def launchCalculateActivity(self,handle):
>                sys.path.insert(1,"/home/zriggle/Activities/Calculate.activity")
>                from calculate import Calculate
>                doActivity = Calculate(handle)
>
>        def __init__(self, handle):
>                self.launchCalculateActivity(handle)

Chris Ball pointed me yesterday to what he's been working lately, and
I think this approach would work quite well in your case:

http://dev.laptop.org/git?p=projects/wikiserver;a=blob;f=activity.py;h=41f5dc73617d91c2981d0f6ef600b7d3ac83b5f4;hb=HEAD

> However, this method causes issues with sugarbot.__init__ never
> completing, which results in exceptions being raised when sugar-
> activity tries to perform some manipulation on a sugarbot object.  The
> only workaround I've thought of so far is to launch a separate thread
> for the called Activity.

Not sure about what's going on without debugging. Try first Chris'
approach, though.

Regards,

Tomeu