How does one even begin with a project whose aim is to change the world? One Laptop Per Child (OLPC) hopes to achieve its goal by changing the way children learn. This transformation is to be achieved by placing a learning appliance in the hands of the children and encouraging them to learn by doing. The appliance is a bundle of an inexpensive, creatively designed laptop and software. The hardware is itself a very exciting product. An interesting product that may have come out of the design of this laptop is a manual charger for mobile phones! While the hardware is visible and tangible, what will make OLPC succeed or fail is the software which goes on it. There is a lot to learn from this software for computer engineers as well.

The system is a constrained device with 256 MB RAM and no swap space. Like embedded systems, we need to work within the framework provided in the device to the extent feasible. The CPU of the laptop is i386 compatible, hence, the development set up for OLPC is far simpler than for, say, the OpenMoko phone, which will require cross-compilation and emulation tools as well.

The GUI framework for OLPC is the Sugar environment. It is based on Matchbox window manager, which is used in Nokia 800 and OpenMoko phone as well. The preferred development language is Python. It is easily accessible even to children and the project leaders want the children to be curious about how the applications work and explore the software. Not by compelling them but by arousing their curiosity.

An application in the OLPC environment is called an activity. It is intended to be a self-contained task not dependent upon any other activities. It should rely upon the common system libraries or package the additional libraries in its own environment. The development system comes with a few activities bundled in but many more are available at http://wiki.laptop.org/go/Activities. Activities are not necessarily simple tasks. Browsing is an activity. It is based on the Mozilla engine though the user interface is very different. TamTam activities allow one to have a lot of fun with sound.

Installing the Development Environment

The dependencies needed on Fedora 7 are available at http://wiki.laptop.org/go/Sugar_on_Fedora_7. The development system works well on Ubuntu as well. The setup should be on a 32bit environment because there are some issues with Sugar on x64 at present.

We follow the instructions http://wiki.laptop.org/go/Sugar_with_sugar-jhbuild and clone the repository of sugar-jhbuild, i.e.

This will be quite fast. The next steps are:

These will download the required packages from various repositories and build them in the local directory. This will take a couple of hours so have some patience.

For running this software, we just use

and it will launch sugar emulator in a Xephyr window. The concept of the Sugar environment is that each application works in a full screen. We see nothing but the activity we are working on. It does not clutter up the desktop and makes it easier to use an activity. This is very different for the user interfaces to which we have become accustomed. Switching between applications is not hard. We move the mouse to a corner and we will get a frame with the available options, including the available activities at the bottom of the screen. The mouse should be captured by the Xephyr window for the above behaviour to work. While developing, keyboard shortcut Alt+F is more convenient.

Anatomy of an Activity

An activity is distributed as an .xo file, which is a zipped file. It is extracted into the activities folder. On a development system, it will be in build/share/activities. In the live environment, it will be in /usr/share/activities. We unzip the file in the activities folder and that is all. Removing the activity is correspondingly simple. Just remove the directory.

Let us say we wish to create a HelloLFY activity. Our folder will be called HelloWorld.activity. It will contain:

Let's start with activity.info

The key line is the class. It informs Sugar of the class to be instantiated for running this activity. Let us now write a program, HelloLfy.py, which is about as small as possible but illustrates the environment.

HelloWorldActivity extends activity.Activity. The constructor calls the parent constructor. It also creates a button and adds it to a frame. We add the standard toolbox of a sugar application. Clicking on the button will call 'hello', which will change the button background to a random colour. Note: each colour's range is 16 bits and not 8 bits.

We also use the standard logging available in sugar framework for help in diagnosing problems.

The package easily built by the command:

To learn more, Redhat magazine has videos and articles on the OLPC project http://www.redhatmagazine.com/category/one-laptop-per-child/. Two articles by John Palmieri about migrating a PyGTK version of Tetris to Sugar environment are very good. A nice side effect was that I could justifiably 'waste' a lot of time playing tetris :)

Wrapping Up

While the focus is on Python and PyGames, a very important activity, eToys, is written in Squeak. Squeak is an open source version of Smalltalk by Alan Kay and friends. One creates drawings and writes little scripts to make the objects of the drawing do things. The goal of eToys is far more complex. It is to help students model and understand complexity. As the site mentions, “It is also important to realize that many systems of thought, particularly those in science, are quite at odds with common sense.” Think about it, shouldn't a heavier object fall faster?

While the project is still under development, new content is being added. For example, Gcompris is partially sugarised. Gcompris is also an activities based learning environment for small children. It is nice to see that some Indian languages are well represented.

Last but not least, networking is an integral part of the OLPC environment. The desire is that every activity should be shareable. A child should be able to invite his friend and they both should be able to play or work together. A simple requirement with very complex software implications.

As one can imagine, there is scope for creating more activities or sugarising and adding sharing to existing applications. These projects can be manageable student projects with the potential of being used by millions. However, the most significant feature of such projects is that they are a lot of fun. But please, do not tell that to the Principal!