A week at LATU (part II): Developing with Sugar

This is the second part of a series of articles about the week I passed earlier this month at Montevideo, working with the Ceibal Plan. See here for the introduction. This post is about the technical issues that were discussed, a subsequent one will go briefly over the management and community issues.

The first hours were dedicated to a quite complete walkthrough of all Sugar dependencies, modules and python packages. Daniel Castelo displayed interest in contributing short descriptions of each package for the API docs, will be great if he finds some time to do so.

LATU's R&D team with Martin Abente and me, photo courtesy of Martin Abente

The next subject we discussed were techniques for easily developing in a regular Linux distro and then testing on the XO. Though since the start of the project we have desired to develop Sugar on Sugar itself, there's still some work to do so you can run a stable instance isolated from the recent changes and a second one running inside it. So the idea is to develop in a machine running for example GNOME and run a Sugar instance inside Xephyr, with its own D-Bus session bus and all. Once you are happy with how it runs there, you can test easily on a XO (or any other target machine) by mounting with sshfs the dirs that contain installed Sugar code onto the dirs with old code. And voilà, an XO running the last unstable Sugar code.

Another area in which developers new to python have generally doubts is with debugging. In languages with a slow compilation process and with direct access to memory, using a debugger such as gdb is often the best first resort, specially if one masters the debugger being used. But in Python, given that between adding a logging statement and running it is such a short lapse, this is generally preferred over a full-fledged debugger. If you already know the code being debugged, you may be already suspecting of some assumption that is not correct, and often with just one more logging statement you can reach the cause. For cases when a debugger is needed pdb is a good equivalent to gdb. If you prefer a graphical debugger, winpdb works well and also allows you to attach to a running process.

Another subject discussed was localization, in order for their work be accepted by upstream, it needs to be fully localizable. We didn't got into details here because it's well explained in the Sugar Almanac, it contains a lot of practical information for activity authors and also shell hackers. Thanks to OLPC for funding the initial work on the Almanac and also to Faisal Anwar and Media Modifications for keeping contributing pro bono.

An issue that was raised several times was a way for Sugar code to execute privileged actions without relying on sudo, as Ceibal's anti-theft scheme relies currently on users not knowing the root password. They plan to remove this limitation soon, but anyway a better way is PolicyKit.

Another important subject was content distribution, they have been bundling books inside a "Library" activity that contains code copied from Browse. Though this is the approach that I like the most in recent releases of Sugar, for their machines running 0.82 I recommended to look at content bundles.

Then they showed the work they have been doing together with Paraguay Educa in adding to Sugar the possibility to connect to 3G networks, using NetworkManager for that (thanks to Dan Williams for his support). Its upstreaming is going smooth thanks to Martin Abente's hard work and the people at LATU are already thinking about extending it for ADSL connections. Kudos as well to Andrés Ambrois for providing a patch for selecting graphically your provider and data plan. This feature is a great example of contributions bringing more contributions, making more worthwhile doing the jump and start working with upstream.

Sugar has survived surprisingly long without printing support. Even if the people actually using Sugar say that they won't actually print much because of logistic issues, this has been mentioned often as the big missing feature in Sugar. In Uruguay the need is mainly for parents whose children bring their XOs home and they have a printer there. Thanks to all the Linux and GNOME infrastructure we leverage, implementing printing support will be much easier than resisting further, so LATU's Daniel Castelo is proposing a way going forward in this issue.

Another subject was sugarizing C applications. This means that the code and resources are all contained in a bundle along with some metadata, the main window would be maximized and have a couple of X properties so the Shell can recognize and track them, and that it implements collaboration with Telepathy and stores its state in the Journal, through D-Bus.

One last subject was discussing how through the extensions mechanism in Sugar they can develop new features without the release cycles causing them to do costly rebases each time.