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.

Akauppi: 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.

Justin: Using macports, I was able to install gtk2 and py-gtk2; however, I was not successful in installing glade. Overall, it was fairly easy to get Sugar running through the QEMU emulator on an Intel-based Mac with OS X 10.4.

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.

NOTE: the latest OS X 10.5 (Leopard) comes with Python 2.5 preinstalled.

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.

what's ridiculous is suggesting a binary installation of gtk+ on mac osx when darwin ports is much simpler and handels the building for you. the porting Imendio is doing doesn't seem quite ready for production considering that there's no link to any zips of source or anything, just the url to the svn repository

If you are running Leopard, don't waste your time (as of Dec 12, 2007) I just spent 2 days using macports and some custom builds to try to satisfy the sugar-jhbuild dependencies, and as much as I hate to admit it - it is currently undoable. There are some real problems in leopard with some of the GNU libs - for one thing any package that includes -export-symbols-regex will compile and install, but fail with "dlopen...symbol not found: xxx" errors when you try to use in python (eg. import gtk) - this problem has been logged on both macports and gnome. You can remove the flag, and some will work, but some, like vte, will not regardless.

In addition, there are numerous other gaps - such as no gst-python port for OSX (the source does not compile out-of-the-box), and the ALSA requirement is likely to be trouble even if you can get past the dep check of sugar-jhbuild. Overall sugar-jhbuild was clearly not designed with x-plat in mind. It would be nice to be able to develop sugar activities on OSX without having to live in a VM environment - but right now that is the only realistic way to do it - at least in leopard.

And the suggestion to use the native GTK+ is silly, it currently breaks just about any of the 500 dependent packages that follow it.

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 reading C or C++ code, you can learn a lot by reading any tutorial material targeted 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. Some developers and engineers think this comes with the territory. The OLPC is very new, only in prototype stage at present. However, the challenge for developers is to make the platform usable by the broad community.

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 educators and allows them to add real value to the childrens educational experience.

There is a large community that has built and contributed to this Wiki. The number of contributors to this wiki is substantially larger than the number of contributors developing usable software for the OLPC. Perhaps the OLPC platform should welcome new and novice developers who may want to contribute domain knowledge in education, but are overwhelmed by the complexity of the platform. Most volunteers have day jobs and will contribute their volunteer time where it seems to have the most impact. For an educator, spending days "working" on getting a development platform working instead of creating educational software, is not a productive use of his/her time. OLPC's goal should be to continue to make the software process friendly.

The External Developers page may be of interest.