Sugar on MacOS X

The currency of this article or section may be limited by out-of-date information. There may be relevant discussion on its talk page

It may be more straightforward to run Sugar in the QEMU emulator as described on this page: OS images for emulation.

For the timebeing, this is NOT going to be a one-click install process. At the very least you will need to install Python and PyGTK separately. And then there is GECKO. And finally, the Sugar environment that is built on all of it.

However, if you can build a pure Python application that uses a simple GUI, i.e. easy to translate into PyGTK, and does not have heavy dependencies, then it will be easy to port into Sugar. Get your proof of concept up and running, fix the major issues and then ask for help to port it to Sugar.

Forward notice: I plan to create a Fink package for Sugar, after which all of this will be a mere sudo fink install sugar. Some dependencies need to be pushed up-to-date first, working on that. If interested, contact me at: akauppi@gmail.com.

Step one: Get Python

First thing is to get Python running on your machine. Python comes preinstalled in OS X, but the universal version available at pythonmac.org is recommended by the Mac Python community for the moment. The Python page has other possibilities.

Step two: Get GTK+

This is the Mac version of the GTK+ GUI toolkit used by the OLPC. It is also the GUI toolkit used by the Open source art program named GIMP. You may want to download GIMP as well to test that the GTK+ is functioning and it will also assist you in dealing with JPEGs, GIFs, PNGs and other image content.

The site for the Mac OS X version of GTK is here http://sourceforge.net/projects/gtk-osx/ but I have no experience with this.

Perhaps you may be able to skip this step if you install GIMP for Mac OS X however OS X allows hiding of libraries inside an application folder so I don't know if this will install a usable GTK+.

The above references are ridiculously out-of-date and misleading. GTK+ 2.x was recently ported to Mac OS X, and the port is part of the standard GTK+ sources. Not quite all there yet, though. The GIMP toolkit for Mac OS X is still 1.2, so it won't work with Sugar, so don't bother with the MacGIMP site, either. All-in-all, I'd suggest working on a Linux box until GTK+ 3.0 comes out.

Step three: Get PyGTK

This is a Python module that allows you to interface to the GTK+ toolkit from Python rather than C++. You can find this here http://ftp.gnome.org/pub/GNOME/sources/pygtk/2.8/ however I have no experience installing this on OSX.

Step four: Get GECKO

This still needs to be sorted out. In the meantime, unless your application relies on displaying HTML, you can get to work on developing the bulk of your application.

Tutorials & Other bits

To begin with, there are some tutorials on the PyGTK website. However, if you have any experience in readin C or C++ code, you can learn a lot by reading any tutorial material targetted to use of the GTK+ GUI on Linux or elsewhere. It is the same toolkit no matter how you interface with it or what OS you use it on.

Glade

A lot of tutorial material uses a tool named GLADE to draw your GUI and save you from writing a lot of code. The Mac OS X version is part of the Darwinports system. Try to use it for your first steps in PyGTK programming because it will help you over the learning curve.

However, if you want to avoid having that XML config file and build your GUI directly, there is a tool called Tepache that can generate Python code equivalent from the .glade file.

Fink and Darwinports

Many applications will use some of the many general purpose utility programs that come with Linux. If you need one or more of these then you can install them from Fink or from DarwinPorts.

Most versions of OS X already have Python installed but it may be older version 2.2 or 2.3. Or it may have various useful modules missing. The packages mentioned on the Python page have bundled together the base Python system with many useful modules that are commonly used.

Overwhelmed

Some people who want to get involved in developing applications for the OLPC are overwhelmed by this complexity. Unfortunately, that comes with the territory. The OLPC is very new, only in prototype stage at present. There are no clear maps of the territory and many details could change in the future. The job of a developer is to deal with all that detail and complexity while crafting something that is simple for the user and adds real value to their educational experience. Simple drill and practice applications will not cut it here.

On the other hand, there is a community to help on this Wiki.

The External Developers page may be of interest.