OLPC development choices

What are my options for developing a piece of software for the OLPC project. From looking at the various sites and wikis, I can honestly say tha开发者_StackOverflowt I am still totally confused. Is it to be sugar, c++, smalltalk or python? HELP!

Thanks,

---

First, the short answer: You want to use Python, and you want to make your python programs "sugarized".

Sugar is not a programming language or development toolkit. It's a GUI environment and "activity" framework. The applications that kids use on OLPC laptops are called "activities", and Sugar provides a bunch of tools for them to use so that they can store their information in the versioned object database (the "journal" from the user's perspective), can show up in the list of available activities, etc.

To make sugarized applications, you write them in python, using the pygtk and/or pygames APIs for graphical work and the Sugar APIs for other Sugar services (like storage, access to the camera, mic, the very cool networking stuff, etc.). You also use a Sugar API to make the program available as a Sugar activity.

You can write C++ code for the OLPC, but Python is the preferred language.

As for Smalltalk, the OLPC project does provide a Squeak environment, but it's intended primarily for kids to play with Smalltalk programming, rather than as a tool for building activities intended to be distributed for use on the OLPC. Not that you couldn't use it that way (I think sugarization of Smalltalk apps is possible -- not sure), but it would be a memory hog. Smalltalk isn't inherently more memory-hungry than Python, but the OLPC devs have done some clever things to optimize Python memory usage. Basically, nearly all of the memory consumed by the Python interpreter is shared among all Python-based activities. Adding a Smalltalk activity to the mix would mean running another interpreter.

You can find lots of activities to look at (with source code) at http://activities.sugarlabs.org. If you develop anything for the OLPC, it's highly recommended that you get a Sugarlabs account and use their git infrastructure (http://git.sugarlabs.org).

I'd also highly recommend that you join the Sugar development mailing list. It's intended primarily for discussion of development of the Sugar platform, but there are very helpful and very knowledgeable people there who can answer questions and point you to the right resources. http://lists.sugarlabs.org/listinfo/sugar-devel

EDIT: Another useful resource for getting started is:

http://wiki.sugarlabs.org/go/Development_Team/Quickstart

---

Faisal Anwar and JediErik developed the excellent Sugar Almanac, which covers a lot of what you need to know to develop for Sugar. It has library descriptions and sample code for topics such as

• creating a valid Sugar activity bundle
• handling presence, threading and internationalization
• interfacing with the Journal and other Sugar-specific system-wide features.
• handling mouse, video, and other inputs

---

Swillden's post is excellent. I will just add a few more points:

People have successfully created Sugarized Squeak activities (see several games from Potsdam University as well as the work by OLE Nepal). OLE Nepal credits the rapid-prototyping aspects of the Squeak environment for their ability to quickly create a curriculum satisfying the desires of the Nepal teachers. I believe that these activities take longer to load, though; as Swillden points out, they lack the "home field" advantage of Python.

I recommend using Python, unless you are significantly more comfortable with the Squeak environment. The approach I used when I developed a Sugar activity (Implode) was to first develop the activity as an application using just Python/pygtk on a standard desktop (Windows or Ubuntu), then port it to Sugar. The code/debug cycle is faster on the desktop since you don't have to switch to an emulator or check error messages in the "Log" activity. If you architect the code right, you can isolate most of the desktop/Sugar differences to a couple modules, so that you can continue to develop and test in both environments. I wrote a pygtk activity, but I expect a pygame-based activity could be created in a similar manner. Of course, if your activity relies on access to certain Sugar-specific features -- like speech synthesis or mesh networking -- this approach may not work as well.

If you want to code in C or C++, whether for performance-critical or legacy code, I recommend writing it as a Python extension module called from a Python-based activity. I believe this is how the Write activity (wrapping Abiword) and Browse activity (wrapping Firefox) are implemented. If you have an existing X application in C/C++, it is possible to make it run under Sugar (see the SimCity, Etoys, and XaoS activities), but it will lack the look and feel of the other Sugar activities.

Finally, I've found the easiest way to add some particular functionality to a Sugar activity is to first find an existing activity that already does it, then read the code to find out how they did it. The Sugar system is not particularly well-documented yet; in some cases the only documentation is the code itself. As Swillden points out, the code for most activities -- as well as for Sugar itself -- is available in the SugarLabs git repository.