Understanding Sugar code

Understanding sugar code

This is an attempt to understand how sugar runs, based on a moderate level of unix shell experience.

What launches sugar?

OK, Sugar runs on an OLPC. The OLPC runs a stripped down Fedora Linux Operating System.

Open the Developer Console, and go to the Terminal tab. Click in the Terminal window, and switch to the root account:

To do this, let's use the superuser command, "su".

[olpc@localhost]$ su

---

What runs as part of sugar? Let's see what processes have the keyword sugar using both the "ps" command to list processes, and the grep command to filter for the processes with the word "sugar" in them.

bash-3.1# ps -eaf | grep sugar
olpc 1290 1285 3 15:46 ? /usr/bin/python /usr/bin/sugar-shell 
olpc 1293 1290 0 15:46 ? matchbox-window-manager -kbdconfig /usr/share/sugar/kbdconfig ... 
olpc 1296    1 0 15:46 ? dbus-launch --exit-with-session sugar-shell
olpc 1298    1 0 15:46 ? /usr/bin/python /usr/bin/sugar-presence-service 
olpc 1302    1 0 15:46 ? /usr/bin/python /usr/bin/sugar-clipboard
olpc 1304    1 0 15:46 ? /usr/bin/python /usr/bin/sugar-nm-applet
olpc 1306    1 4 15:46 ? python /usr/bin/sugar-console
olpc 1339 1285 1 15:46 ? grep sugar

Most things seem to run on python, not a big suprise. But right here, we can see some key architectural divisions:

1. A shell
2. A presence service (the right side of the sugar interface)
3. A clipboard (The left side of the sugar interface)
4. A nm applet utility of some kind (This might be the bottom stuff in the sugar interface)
5. A console (probably the development console)

Also, there are two non-python type processes running, dbus-launch, and a matchbox-window-manager. I think matchbox is an automated test utility (notice it's spawned from the sugar-shell), and the dbus is for Inter-process communications (supporting the presence service, amongst other things)

Matchbox is the windowmanager. See Matchbox home page

So the questions are...

What starts the sugar shell? What is each service or utility?

---

It looks like most of these python scripts are stored in /usr/bin. We can read the python scripts and see what they do.

bash-3.1# less /usr/bin/sugar-shell

This thing starts a sugar environment. It also relies on a lot of other stuff, and it looks like the OLPC developers expect a lot of changes here as they make progress on getting sugar into shape. It references GTK, dbus, nm applet, and lots of stuff.

bash-3.1# less /usr/bin/sugar-nm-applet

Oh, look, this is the network manager utility. OK, and then the activity factory will be triggered whenever a new activity is selected on the bottom....

[initialization]

The sugar-shell process has a parent of 1285...

bash-3.1# ps -eaf | grep 1285
olpc 1285 1269 0 15:46 ? xinit /home/olpc/.xinitrc -- -auth /home/olpc/.serverauth.1269

How about that? In the olpc home directory, there is a hidden .xinitrc file. Let's look!

bash-3.1# less ~olpc/.xinitrc

Well, this thing launches both the tinderbox and the sugar-shell. It looks like the sugar shell is launched within the dbus-launch utility.

So that's where the sugar user interface starts... it's:

exec dbus-launch --exit-with-session sugar-shell

We can read down from the sugar-shell and read almost all the code from that point down. That's pretty nice.

What sugar python library does /usr/bin/sugar-shell load?

bash-3.1# python
>>> import sys
>>> import sugar
>>> dir(sugar)
['ZOOM_ACTIVITY','ZOOM_FRIENDS','ZOOM_HOME','ZOOM_MESH', etc.. ]
>>> sugar
<module 'sugar' from '/usr/lib/python2.4/site-packages/sugar/__init__.py'>

That seems pretty definitive. Looking in the /usr/lib/python2.4/site-packages/sugar directory, there are all sorts of interesting files.

ls/usr/lib/python2.4/site-packages/sugar/*

There are some interesting directories:

activity
chat
clipboard
datastore
graphics
p2p
presence

But the python scripts are even more interesting:

Traceback.py
emulator.py
env.py
logger.py
profile.py
simulator.py
util.py

In particular, the logger.py & env.py are here. It would be nice to see what the sugar-shell script actually does, and we are ready to try it manually. I'm going to skip stuff that doesn't seem right yet.

bash-3.1# python
>>> import sys
>>> import os
>>> from sugar import logger
>>> from sugar import profile
>>> from sugar import env
>>> dir(env)
[..., 'sugar_activities_dir', 'sugar_activity_info_dir', 'sugar_data_dir', 'sugar_services_dir', ...]
>>> env.sugar_activities_dir
'/usr/share/sugar/activities'
>>> env.sugar_data_dir
'/usr/share/sugar'

Now we know that the three directories that house sugar python scripts are /usr/bin, /usr/lib/python2.4/site-packages/sugar, and /usr/share/sugar. That's a pretty good day's work.

How does sugar initialize?

Next, let's look slowly at what happens as sugar initializes.

/usr/bin/sugar-shell is a python script: #!/usr/bin/python

It imports os & sys, and the pygtk. Then sugar makes sure the pygtk libraries are in the path by calling a function that adds the path if it's not there. This is just a bit of robustness.

Next, import a bunch of sugar functions into the top namespace of the python environment... We can see all the names in the top namespace by using the dir()

bash-3.1# python
>>> import sys, os, pygtk
>>> pygtk.require('2.0')
>>> from sugar import logger, profile, env, TracebackUtils
>>> dir()
['GIntiallyUnowned', 'TracebackUtils', ..., 'env', 'logger', 'os', 'profile', 'pygtk', 'sys']
>>> logger.cleanup()
>>> logger.start('shell')
>>> sys.path.insert(0, os.path.join(env.data_dir(), 'shell')
>>> env.data_dir()
'/usr/share/sugar'
>>> sys.path
['/usr/share/sugar/shell', ... the regular python path ]

This is initializing the logger function, and then setting up our python path to look at /usr/share/sugar/shell first. That makes the shared sugar shell scripts take priority in our environment.