Progress on Sugar activities with SWF content

Following the work I did some months ago, Rob Savoye has been kind enough to update the rpm spec of Gnash to also produce rpms for the SDK and for the python bindings for embedding the player.

This will allow us to run activities that use Flash content in the next release of Sugar, 0.86. Rob has also updated the .deb control files so this work is well under its way to be in the next releases of all the major distros.

If you want to try it today, you can install some rpms in the Fedora 11-based Sugar on a Stick and run EatBoom, a sample activity that contains a flash game developed by Innovations for Learning. It is a simple game for practising additions that is part of their TeacherMate product. IFL has released this activity as GPL and I hope they will find value in releasing more of their work so it can be used by children in Sugar or in other platforms.

Step 1: download the last SoaS snapshot from here.

Step 2: install it to a USB stick following this instructions and boot it in your computer.

Step 3: start the terminal activity and run the commands below:

su -
curl -O http://shell.sugarlabs.org/~tomeu/gnash/gnash-0.8.5-4.20090615bzr11113.fc11.i586.rpm
curl -O http://shell.sugarlabs.org/~tomeu/gnash/gnash-plugin-0.8.5-4.20090615bzr11113.fc11.i586.rpm
curl -O http://shell.sugarlabs.org/~tomeu/gnash/gnash-widget-0.8.5-4.20090615bzr11113.fc11.i586.rpm
rpm -U *.rpm

Step 4: start Browse and type the following URL: http://shell.sugarlabs.org/~tomeu/EatBoom-1.xo The EatBoom activity will be downloaded and installed.

Step 5: Run EatBoom!




Here you have the source for the activity, which can be changed to load a different SWF movie by changing just a single line of code: http://git.sugarlabs.org/projects/eatboom

Installing Mozilla addons in Sugar's Browse

Lucian Branescu thinks it would be useful for his Webified project if Browse could run Google Gears.

Browse is unfortunately unable to install and directly use .xpi files, even if it's based on Mozilla. Maybe adding support for this doesn't depend on too much stuff only in Firefox and it could be quite easy. If someone would like to investigate a bit, would be very nice. But for now we can do some dirty tricks to get it up and running.

Steps:

• expand gears-linux-opt.xpi with unzip,


• move the files inside the components dir (bootstrap.js, gears.xpt, libgears_ff2.so and libgears.so) to $(prefix)/lib/hulahop/components,


• move the file inside the lib dir (update.js) to $(prefix)/lib/hulahop/lib,


• move the dirs inside the chrome/chromeFiles dir (content and locale) to a new dir called $(prefix)/share/hulahop/chrome/gears,


• copy the file chrome.manifest to $(prefix)/share/hulahop/chrome/gears.manifest, mind the file name change. Also make this change to the file contents:


--- chrome.manifest 2009-05-19 20:34:46.000000000 +0200
+++ ../../install/share/hulahop/chrome/gears.manifest 2009-05-29 12:26:36.000000000 +0200
@@ -1,4 +1,4 @@
-content gears chrome/chromeFiles/content/
+content gears gears/content/
overlay chrome://browser/content/browser.xul chrome://gears/content/browser-overlay.xul
locale gears en-US chrome/chromeFiles/locale/en-US/
locale gears ar chrome/chromeFiles/locale/ar/


That would be enough, but unfortunately Gears will be of little use for now until this bug gets fixed in Mozilla, because the security dialog will be too small and you won't be able to authorize web sites to use Gears. Let's hope this gets fixed soon!

And now for the obligatory screenshot:

Ad-hoc wireless networks in Sugar

During the Sugar Camp in Paris a couple of weeks ago, Gary C. Martin and me played with ad-hoc networking between OSX and GNOME. It turned out to work flawlessly and we thought that it could be a good substitute for OLPC's mesh network, as Bonjour traffic won't saturate the spectrum if using plain ad-hoc. And it has the great advantages of being able to work on most wifi cards and not requiring any changes to NetworkManager.

So a few hours of hacking brought these results:



The user called tomeu-soas, running Sugar on a stick on a SD card on a Eee PC, creates new adhoc network.



We can see in the neighborhood view that a new network appears, called "tomeu-soas's network".



On a OLPC's XO running as well SoaS, we can see the new network appear in its neighborhood view. Eventually the colors of the network should match the colors of the user that created it.



Once we connect to this network, telepathy-salut kicks in and shows the presence of the other people connected to this same ad-hoc network.



A GNOME desktop can also join the network and interact with Sugar clients if it has Bonjour-enabled clients. In this case it's Pidgin, but any applications that implement some kind of sharing via telepathy-salut will be able to collaborate with Sugar activities that implement the same protocol, like for example Abiword.



And this is how the Chat window looks in the XO.

So I hope that this new feature will make easier for children to collaborate across the network, chat and exchange files without their government having to buy a minimum of 100k XO laptops.

Thanks go to Gary for his brain cells, Dan Williams for some troubleshooting help (and writing the awesomer-than-most-people-say NetworkManager) and to Simon Schampijer who wrote the current NM client code in Sugar in such a way that my patch is really tiny. And also to Collabora for having contributed the code that allows normal bonjour and jabber clients interact with Sugar.

Reducing Sugar's memory usage

One of the biggest performance problems of Sugar is caused because we use a lot of python modules. This is worst in python than in C or other languages because the bindings for these libraries need to initialize a big bunch of stuff when they are loaded and that takes quite a bit of cpu time and of memory that never gets released.

The visible effects of this are slow startup of activities and occasional system crashes on systems with little memory and no swap as the OLPC's XO.

In the past weeks I have been working on improvements to PyBank so it can run Sugar. PyBank will allow us to use any library based in GObject without having to load a bindings module. I have measured a reduction of memory usage of more than 4MB (from a total of 22MB) for the shell, though I haven't managed yet to run it with all its functionality due to missing pieces in gobject-introspection and PyBank. Each other process that previously used pygtk (almost every base activity) will show a similar reduction in 4-5MB.

I have big hopes for this because we'll get these additional benefits:

- we'll be able to run more activities simultaneously,

- we'll be able to run on systems with less memory,

- we'll be able trade some of the memory savings for compositing some windows so less redraws will happen, leading to a more responsive UI,

- the shell and activities will start much faster,

- by moving the sugar toolkit from python to a GObject library with introspection support, we can completely drop several python modules thus reducing further the footprint. Also activity authors will be able to use the toolkit from languages other than python.

Now, the bad news is that though we have made great advances in this plan, we have only a few months until the next release. My current estimation is that I would need most of that time in order to bring the needed infrastructure to the needed level of maturity, and even then we'll face most probably issues regarding the packaging of the various pieces in all the distros where we want Sugar to be well supported.

So right now my opinion is that we should put this effort to rest for a few months while the base components mature and get packaged for distros and then come back to it after 0.86 is released. Hopefully by 0.88 we'll have a much leaner and faster Sugar leading to more learning for children like this:



If someone wants to hack further on this, you will need to checkout and install the following modules in sugar-jhbuild:

http://git.gnome.org/cgit/glib
http://git.gnome.org/cgit/pygobject/
http://git.gnome.org/cgit/gobject-introspection/
http://git.gnome.org/cgit/gir-repository/
http://git.sugarlabs.org/projects/pybank/repos/mainline
http://git.sugarlabs.org/projects/sugar/repos/sugar-pybank
http://git.sugarlabs.org/projects/sugar-toolkit/repos/sugar-toolkit-pybank

Then you will need to convert the sources in sugar-pybank and sugar-toolkit-pybank with the sed script in sugar-pybank called pybank-convert.sh .

Johan Dahlin has been of great help during this time, his deep knowledge of pygobject has been invaluable. Also go thanks to Simon Schampijer, Marco Pesenti Gritti and Bernie Innocenti for their moral support. We'll get there, eventually! ;)

Embed flash movies with gnash in your gtk apps

Has been a week full of hacking fun since I started to work on a Gnash gtk widget. Some frustration as well because it's the first time I deal with C++ code using boost and modern stuff like std_ptr and, of course, libtool and friends. This bit of work comes in line with my earlier posts about embedding Evince, Abiword and Mozilla.

But the effort has born its fruits, and now we can run all of Gnash as a gtk widget inside a Sugar activity:


And this is the code:

import os

import gtk
import gnash

from sugar.activity import activity

class EatBoomActivity(activity.Activity):
    def __init__(self, handle, browser=None):
        activity.Activity.__init__(self, handle)

        toolbox = activity.ActivityToolbox(self)
        self.set_toolbox(toolbox)
        toolbox.show()

        view = gnash.View()
        view.load_movie(os.path.join(activity.get_bundle_path(), 'EatBoom.swf'))
        view.start()
        self.set_canvas(view)
        view.show()

For non-Sugar-enabled gtk people, you will be able to embed gnash doing something like this:

    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    
    view = gnash_view_new ();

    gtk_container_add (GTK_CONTAINER (window), view);
    gtk_widget_show (view);
    
    gtk_widget_show (window);

    gnash_view_load_movie(GNASH_VIEW(view), argv[1]);
    gnash_view_start(GNASH_VIEW(view));

This is without using GtkPlug and, of course, running inside the same process. So by adding methods to the C widget we can control all of the Gnash engine and expose it trivially to python with pygtk. And through the use of Gnash extensions, we can extend the ActionScript class library with Sugar specifics so it integrates well with the rest of the environment.

This is still a proof of concept, but plan to start working right now in finding a way to integrate it in upstream Gnash.

What keeps me going on?

Something I have to answer myself approx. one out of two mornings before I get out of the bed, is why I'm going to pass the next 10 hours in front of the computer doing Sugar stuff.

Basically, it ends up being a matter of reevaluating the chances that Sugar keeps improving as an educational platform and that the newer versions are made available to more children, who presumably would have less educational chances otherwise. Fortunately, I keep being very optimistic about this, so I'm able to get up and go back to Sugar coding as usual without much fuss.

But at some point during the day I will feel tired, frustrated and discouraged by one thing or the other and will need to find encouragement from somewhere else. And lately what encourages me most is to see the work that very talented individuals are pouring into Sugar.

So for folks that need as well a source of inspiration, below is a small list I've done in the last months of the 0.84 release cycles. Keep in mind that this isn't an extensive credits listing but a subjective list of the people that surprised me with their enthusiasm and awesome work. People like Bernie Innocenti, Caroline Meeks, David Farning, Mel Chua, Walter Bender and several others have very important roles but I'm already used to them so I'm not so surprised ;)

Aleksey Lim: appeared one day in #sugar talking about packaging Sugar for ALT Linux and ended up packaging it as well for Gentoo, Mandriva and Caixa Magica. Not satisfied with that, he also took maintenance of several orphaned activities and submitted patches for others, also making sure the Sugar on a Stick images were full of interesting activities. After only three months of work in this project, he has become a very important of it.

Christian Marc Schmidt: apart from his excellent work in the Pentagram team contracted by OLPC, Christian has kept contributing to Sugar Labs as a volunteer. During the 0.84 cycle he presented with Eben Eliason in the SugarCamp their ideas about the future of the Sugar experience and designed, produced and deployed a new static site for Sugar Labs that I personally love.

Dongyun Lee: has contributed a very beautiful graphical story about learning with Sugar, check it out for yourself.

Jameson Chema Quinn: Has made a wonderful start coordinating this year's Google Summer of Code program. Though most of the work is still to come, seeing how individuals stand up and take less glamorous but strategically vital tasks makes me feel we really have a bright future in front of us.

Sascha Silbe: Similarly to Chema, has taken one task that wasn't well covered to date but that is very important to grow the community of developers. He will be taking care of sugar-jhbuild (how most developers run and test Sugar) and the build bots that monitor that the last development version of Sugar has a minimum level of quality.

Sean Daly: Greg Dekoenigsberg worked hard during the last year in the marketing side of Sugar Labs, helping us communicate why Sugar is relevant for both users and contributors. Unfortunately, other duties made Greg scale back the amount of time he can dedicate to it, but his call for a successor has been wonderfully answered by Sean. He has led the Marketing Team with skill and is coordinating a media campaign with enormous professionalism. It's very comforting to know that communicating the fruits of your work is in such good hands.

Sebastian Dziallas: There's no point in having a testing period before release if you cannot run the software. Sebastian took the task of producing images that after being copied to USB sticks allow you to run Sugar on most computers. Martin Dengler, Simon Schampijer, Chris Ball and Aleksey Lim contributed to this effort, but Sebastian has been leading with excellent community and technical skills.

Simon Schampijer: I prefer not to think what would have been of the 0.84 release without him ;) He has carried this enormous responsibility with grace, after learning the tricks of the trade from Marco Pesenti Gritti, who for personal reasons has also needed to scale back his involvement in Sugar. And I learned with joy just the other day that he's volunteering to be the release manager for 0.86!

Wade Brainerd: A long time contributor to the OLPC project, he took the enormous task of leading the Activity Team. Since the start of this project we have said that activities are what really bring value to the user, but have heard the criticism that core Sugar developers were too busy with the Sugar shell and didn't devoted enough time to empower activity authors. Well, this is changing now because activity authors are taking the lead and are getting together to tell us what to do! I think that the activity team is still the embryo of what needs to become, but has already shown a very good start.

But the best thing is trying to imagine all the new people that will jump on the Sugar wagon in the next few months. We have lots of hard challenges ready to take by talented people that want to make a difference for several hundreds of thousands of children all around the world. Don't stay watching on the side, join us!

One more call for help: please upload your activity bundles

Activity maintainers, please upload the latest versions of your activity bundles to http://addons.sugarlabs.org.

Also, note that you can now upload screenshots of your activity, see the "Edit previews" link in the editing options.

Thanks!