Tag Archives: activity

Quick notes on the OLPC XO Terminal Activity

Originally published on joviko-olpc.blogspot.com January 6, 2008.

Well, I’ve realized that to really figure out what I did right / wrong to get DOSBox sound working on the XO, I’ll need to reimage the OS and start from scratch, and I’m finding all kinds of things to do to avoid going down that road just yet.

One of them is looking at the Terminal Activity as part of my process for learning how to create a good Sugar-friendly Activity. Plus I’m hoping that it might be something that I can hack into the “Sugar wrapper” that can be used to run non-Sugar-ized apps as Activities on the XO without having to put Sugar hooks into their internals. In other words, an Activity that launches from the Sugar “Activity launcher” screen, displays an icon in the “active Activity ring”, runs the non-Sugar app, then tells Sugar to remove the icon from the “ring” when the app exits. This would be very handy for Activity-izing apps like DOSBox and other emulators. And thus for running old freeware DOS and Apple programs on the XO.

Anyway, the Terminal Activity is pretty neat. The source code is very short, consisting of about 200 lines of Python. It uses a Python library called ‘vte’ to do all of the heavy lifting. ‘vte’ is, to put it mildly, a bit underdocumented. ‘vte’ is essentially a Python wrapper around the Gnome VTE widget.

So, to help others who might be curious about how the Terminal Activity does its thing, here are some handy links:

The Terminal Activity source code

earobinson’s example Python vte.Terminal window
He ordered a G1G1 XO in November, so maybe we’ll hear more from him…

The magic of Google code search lets us browse the vte source files
Of particular note: The “README” file, the “python” directory (and “python/vte-demo.py” in particular), and the sparsely populated “doc” directory.

The Gnome VTE Reference Manual
Not as useful as I had hoped, but does list out the API.

Happy hacking.

A couple of handy OLPC XO Sugar utilities

Originally posted on joviko-olpc.blogspot.com January 23, 2008.

I’ve recently been working on a few new Activities for the XO. As a result of this, I’ve discovered that there isn’t a complete set of utilities for dealing with Sugar’s internal tracking and record-keeping of Activities.

You can use the Journal Activity to install the “.xo” files for new Activities. You can use the Sugar Activity toolbar to “remove” an Activity. This removal is far from effective; it oftentimes does not actually delete the Activity’s files in /home/olpc/Activities, and just as often, it doesn’t remove Sugar’s internal record of the Activity.

You can also manually install Activities via the ‘sugar-install-bundle’ utility, which can be run from the command line in the Terminal Activity. However, if you’ve already installed and then removed an Activity, it is very likely that ‘sugar-install-bundle’ will crash, complaining that the Activity already is installed, since Sugar never deleted its internal record of the Activity. This can be very frustrating when you’re testing the installation of a new Activity, and need to remove and reinstall it multiple times.

I ended up poking around in ‘sugar-install-bundle’ (which is a Python script), and discovered that it calls some other Python modules in /usr/lib/python2.5/site-packages/sugar. These, for someone hoping to create an Activity, might be worth looking at, particularly the ones in the “activity” and “bundle” subdirectories. “…/activity/registry.py” is a particularly good one.

After all that poking, I saw the classes and functions needed to list all of the Activities that Sugar currently is aware of. These are stored in Sugar’s registry (a binary database similar in use to the registry under Windows). I also saw how to remove the entry for a specific Activity from the Sugar registry.

Each entry has a name (e.g. “Sonata”), an icon, a “bundle ID” (“com.ywwg.Sonata”), an installation path (“/home/olpc/Activities/sonata.activity”), a command to launch the Activity (“sugar-activity SonataActivity.SonataActivity”), and a show-launcher indicator.

The Activities appear to be accessed and referred to by their installation paths, rather than their names or bundle IDs (which is a bit surprising to me, but using the path as the primary access key may allow both the names and IDs to be non-unique).

I’ve created a couple of handy utilities, ‘sugar-list-bundles’ and ‘sugar-forget-bundle’. Both are short Python scripts, and can be run from the Terminal Activity’s command line. They can be downloaded in a “.zip” file from here.

‘sugar-list-bundles’ doesn’t take any arguments. It just dumps out the info on all the Activities currently listed in the Sugar registry. It lists the name, ID, path, and command for each Activity. To run it from the command line (assuming you’ve unzipped the utilities into the current directory):


‘sugar-forget-bundle’ takes one argument, the name of an Activity. This name must exactly match one of the names dumped out by ‘sugar-list-bundles’ for ‘sugar-forget-bundle’ to be able to use it. ‘sugar-forget-bundle’ will remove the Activity’s record from the Sugar registry. It will NOT delete the directories or files associated with the Activity. For example:

./sugar-forget-bundle Sonata

will cause Sugar to “forget” that the Sonata Activity is installed. It will NOT remove /home/olpc/Activities/sonata.activity or any of the files under it.

I’m sure there must be equivalents to these two utilities floating around (especially around the OLPC XO development team), but I haven’t stumbled across them. I hope you find them handy.