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.

A week at LATU (part I)

LATU stands by Laboratorio Tecnológico del Uruguay and is in charge of the technical aspects of the Plan Ceibal, as well as the overall coordination of the project. As part of their responsibility in making the software deployed on the OLPC machines as useful as possible in their context, they are spending considerable resources in the development and support of Sugar.

Because they were until recently on the initial phase of the project, they have carried that work on their own, without participating in the community nor working together with other deployers of Sugar. Now that every child in public primary schools in Uruguay owns a XO laptop, they are starting to think about optimizing their Sugar work by pooling resources with others and coordinating with upstream's schedules. The LATU also has a big interest in that their work benefits other countries using Sugar, as part of Uruguay's participation in international cooperation. I have the hope that most of what they learn when working with Sugar Labs will help them take the most of other free software projects they use, such as GNOME (chances are the laptops that will be given to high schoolers in the next years will be running that).

The concrete issue they found when developing on their own was that every time that their upstream (OLPC) produced a new image build, in order to benefit from the improvements in that release they had to apply the customizations made locally, solve any conflicts and retest everything. If they had contributed those modifications to Sugar, OLPC images would have come with them and no further work would be needed. Reaching the point in which they can directly use the OLPC images as-is is still a bit far away, but every bit that they integrate upstream is a step in the right direction and reduces their development and support costs. Also, when their employees work within the communities that maintain their software, they work directly with the most qualified engineers in those technologies, increasing local capacity.

Through Walter's mediation, Miguel Brechner contacted me a few weeks ago proposing visiting them in Uruguay to explore ways for integrating their processes with those in Sugar Labs and other free software projects they use such as OLPC. I was lucky enough to be able to take the chance to also attend Ceibal '09, a wonderful event about which I blogged here.

Another happy circumstance is that the LATU took the initiative of inviting Paraguay Educa, the deployers of OLPC and Sugar in Paraguay, to send one of their engineers to Montevideo in order to participate on the sessions. It was a big pleasure meeting Martin Abente (tch in #sugar), who wrote about his trip (in Spanish) here and hope I can meet in person the rest of his team soon.

This is the first time since a year ago that I have been paid for working on Sugar, so I have high hopes in that we are going to find soon business models that will sustain further development of Sugar. Would be a sad situation if upstream development of Sugar had to halt because the core developers had to end their involvement in order to fulfill their real-life responsibilities. If that happened, deployers of Sugar (responsible for more than a million installations) wouldn't have a place where to pool resources and coordinate their work.

I'm going to blog two more parts about the week I spent there, one focusing on the technical aspects and the other will be about the management and community side of things.

Ceibal '09

In the days 7th and 8th of this month took place in Montevideo the First International Event on Experiences about the Ceibal Plan, with the objective of sharing the experience gained during the first years of the implementation in Uruguay of the OLPC initiative, with the name of Plan Ceibal. On the afternoon of the second day, some schools displayed the work they had done with the XOs.

Project Rayuela and LATU were kind enough to invite me to assist, which has been an unforgettable experience for me. The plan was that after the event I would stay for one week discussing with the software team at LATU how they can work most profitably with the Sugar community upstream, will talk about this in a later post.

I still can hardly believe that it has been the second time that I have been close to a child learning with Sugar, and the previous one was more than 2 years ago, when attended FISL in the company of J5 and Jim Gettys. We visited then a school where the Federal University of Rio Grande do Sul was conducting a pilot with very early prototypes of the XO and Sugar.

Visit to the school Luciana de Abreu

This time was very different because we were seeing the results of at least one year of continuous work with Sugar, something that was happening in the mainstream of that society, backed by the government, the families, several volunteer organizations, and the primary education system.

Students displaying their work with Scratch

Though I was ecstatic seeing each school presenting their work, I felt a bit sorry for the developers and non-developers that made that possible with their work but received very little feedback to date on the actual use of it. I have plans to improve that.

Learning geometry with Turtle Art

It has been a very enlightening and encouraging experience, wish all my colleagues at Sugar Labs could have this opportunity as well in the near future. The last 2 years have been pretty hard for the Sugar developers, always having to stand the never ending stream of naysayers, even from OLPC itself, and with the last year having to live off our savings. I'm very proud that we have managed to stand firm on our believe that the best GUI for learning hadn't been invented yet and that we could contribute something valuable to the mission of giving more learning opportunities to children around the world, specially those from less favoured backgrounds.

After having seen children and teachers involved together in learning with Sugar, I can finally say that we were right. Though of course, this is just starting...

The program of the event can be found here and I expect that soon will appear video recodings of the sessions and of the school presentations. Will post here when they are made public. Also will post soon about the week that followed, in which I had the luck of being a small part of a process in which an organization (and in some sense, a country) moves from being a consumer of FOSS to being a full rights member of the FOSS community.

Thanks to J5 and Gonzalo Odiard for the photographs.

Can GNOME change the world?

Maybe, after all ;)

Almost one year ago I blogged here about ongoing work in adding file transfer capabilities to Sugar. That work was prompted by some Collabora employees pinging us about this new feature in the Telepathy spec, they were helpful when implementing the client side in Sugar and also surprised us by implementing support in telepathy-gabble just in time for Fedora 11.

Since then that feature got released in Sugar 0.84 and refined in 0.86.

And last week, Jose I. Icaza from TECno.tzotzil blogged about how small children in remote schools in the Mexican region of Chiapas are exchanging their writings across the network and teaching their teachers to do the same, using Telepathy.

Don't know about you, but I find amazing that the time I spend hacking on something cool can also have a positive impact on the education of children all around the world, specially in the poorest and most remote areas.

If you would like to use your hacking skills to improve education and wonder how, please refer to this post.

Free education as in free speech

It's great to see more and more fellow FLOSS enthusiasts realizing both the impact of education in our goals and the importance of free software in improving our society, this time by impacting children's education.

Celebrating tomorrow's Software Freedom Day, the Free Software Foundation and Sugar Labs are announcing a partnership to improve learning with free software:

http://www.fsf.org/news/sugar-labs
http://www.sugarlabs.org/press

If you are a software developer concerned about the challenges that our global society faces and think that early education is part of the solution, please consider contributing to Sugar Labs. You don't even need to get your hands dirty in Sugar code if you don't wish to, there's plenty of code elsewhere in the stack that will benefit our young users, for example:

* Improve the rendering performance of librsvg for the kind of icons used in Sugar,

* Add tile-based rendering to Evince #303365,

* Improve GObject-Introspection support in PyGObject (what used to be called PyBank),

* Improve startup performance and memory usage of Python by reducing eager loading of module dependencies,

* Improve Linux' handling of low memory conditions in userspace,

* Package Sugar for your favorite distro,

* Improve the infrastructure for Live USB images in your favorite distro,

* Spread this call for help.

Of course, if you prefer to help us develop the Sugar shell and its activities we'll be happy to help you put your skills on use. Just say hi in #sugar @ Freenode or in sugar-devel.

And as any other FOSS project, we also need testers, bug triagers, designers, web developers, technical writers, you name it.

Writing Sugar activities with PyQt

At David Boddie's suggestion, have dedicated part of this weekend to explore how well PyQt can be used to write Sugar activities. The results have been very satisfying, I would say thanks to python's flexibility and to the Sugar activity architecture, an excellent work of Marco Pesenti Gritti.

So I got something that looks and behaves similarly to activities compliant to the Sugar Human Interface Guidelines, with the following exceptions:

* No combobox for selecting the sharing mode.

* Some theme quirks were fixed with a custom stylesheet, I think these should be treated as bugs in either QGtkStyle or the Sugar Gtk theme. Or if QGtkStyle is not up to this job, we would need to implement a new QStyle. Couldn't workaround all of the issues in the stylesheet.

* No palettes at all. Hope implementing them in Qt will be much less work than it has been in Gtk+.

* The XCursor theme is not picked up, need to investigate further.

* Some Gtk stuff is still used, I think PyQt activities shouldn't use Gtk+ at all for better memory usage and startup performance.

Good news is that I have reimplemented good part of the activity API in PyQt quite quickly, but we may want to design a better API learning from the mistakes of the past.

Now, let's let the Sugar platform get flooded of KDE Edu activities :)

Update:

Code: http://git.sugarlabs.org/projects/hellow-world-qt/repos/mainline

Screenshot:

On Negroponte's omelettes

For the people who aren't following closely the Sugar project (specially my GNOME friends), if you read in certain media that Negroponte thinks that Sugar is OLPC's biggest mistake, you may want to know that some confusion has arisen from his badly-chosen words.

Negroponte is referring by the name Sugar to the whole OS image that ships in their machines, something different to what everybody else refers by Sugar, even OLPC's own Support FAQ.

No need to extend on this myself because others have explained better the gory details:

http://radian.org/notebook/nonsense-omelet
http://gregdek.livejournal.com/52052.html

Something I can add to those posts though is that OLPC management tried once before to refer to the whole software they made as "Sugar" at one occasion before. It was when the community was outraged at the company's approximation to MS, they announced that their commitment to Sugar was still strong and proof of that was that they had doubled the resources available to Sugar.

What in fact happened was that they hired several people to work on the base system, but the people working on the real Sugar were still the same, sad, 2 and a half people.

Given that the Sugar community is working in the benefit of OLPC's customers, I wonder why Negroponte cannot think a bit more before making such "courageous" statements.

Telepathy Developer's Manual

I'm skimming through it right now and this is REALLY good stuff:

http://people.collabora.co.uk/~davyd/telepathy-book/

Ideally, 90% of Sugar activity authors shouldn't need to get to work much with telepathy directly, because they most likely only want to share a data structure and interchange some messages or signals.

But for the people doing activities such as Chat or VideoChat, implementing collaboration frameworks such as Groupthink or messing with the presence service in Sugar, this will be invaluable and will hopefully lower the floor for new contributors.

Thanks, Collabora!

Sugar, usando Software libre para aprender

Por casualidad tropece con este articulo excelentemente escrito por Maria del Pilar Saenz Rodriguez: Sugar, usando Software libre para aprender. Explica muy bien la importancia del software libre en educacion y como encaja Sugar ahi.

Desafortunadamente se necesita Flash para acceder al pdf, esta disponible en la caja "My shared files" en la misma pagina. Y claro, seria muy bueno que Pilar alias befana sindicara su blog en planet.sugarlabs.org.

Tambien seria estupendo tener una traduccion al ingles para la gente de Sugar Labs que lo promueve a nivel internacional, voluntarios?

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!

Call for help: pyabiword in Ubuntu Jaunty

Seems like, unless we make a strong final push, Write and other cool activities that make use of abiword won't run out of the box on the next Ubuntu release. This would mean a significantly less useful Sugar on what may be the widest available Linux distribution.

It would be a real pity because, in addition to the great work that Debian and Ubuntu packagers have already put during the last weeks, we'll have to tell people to use any of the other distributions that will package the whole of Sugar 0.84: Alt Linux, Fedora, Gentoo, Mandriva, openSUSE and Caixa Magica Magalhaes (as per http://sugarlabs.org/go/DevelopmentTeam/Packaging).

We still may have time to change this fate if we manage to convince the Ubuntu developers to accept a patch that will build abiword with the libabiword support we need, and package pyabiword.

So this is a call for people that can help with:

• modify the abiword package in Ubuntu to produce libabiword.so and the accompanying -devel stuff,


• package the pyabiword bindings,


• push this through the Ubuntu processes so it gets into their next release,


• forward this call for help to other forums.

Who in this community can help with this or knows someone who may be able to help?

Please update the wiki page linked above with the status of your efforts.

desktop specialization

Two recent posts in the GNOME Planet broadened my belief in that Sugar can give something back to the GNOME community.

Stormy's GNOME Mobile: bringing the desktop and the internet together:

While most people outside of GNOME Mobile probably think of cell phones when they think of mobile, GNOME Mobile is really about making the desktop fit the new form factors (phones, netbooks, devices, ...) and making it work well with a non traditional user interface.

J5's 10 thoughts on what is needed for the Linux Desktop to win:

#5 Forget about the general purpose desktop - ok don’t forget about it upstream but when making a product you are going to run into the “this doesn’t work like Windows” syndrome. [...] The general purpose desktop is just too big a target and will always get compared to the current leader.

I think that they pointed out the two most relevant aspects that define how Sugar relates to GNOME Mobile:

- adaptation to new form factors, and

- search for an user experience better suited to a well-defined population group.

And not only because of the very good marketing reasons that J5 mentioned, but mainly because what works for an office worker may not work best for a young learner. So doing things differently is critical to our mission.

I hope that other people will also realize that computers are not only useful in an office context and that we need to adapt to the new times. And hope as well that many will choose GNOME Mobile as a base for their products.

I'm happy to say that the GNOME bits we have been using to date have worked pretty well for us, and more importantly, each release brings more and more goodies that are specially useful in our niche.



At the talk I'm going to give this week at FOSDEM, I will point out how GNOME Mobile was useful for us and which are our biggest issues and how we could move forward.

Sugar now on Mandriva's cooker

Today I managed to run Mandriva's development stream (cooker) on kvm-qemu and gave a test to the Sugar packages that Aleksey Lim has been working on during the last weeks.

And all I have to say is big kudos to Aleksey. Thanks to him we have Sugar on the path to be well supported in one more major distribution, and one that is working hard to put linux to work on education.

Galeon and learning

Reinout van Schouwen said about Embedding Mozilla...
> Let's build a GTK+ shell around it and call it Galeon! =)

Actually, that's an interesting point. What I talked about is more like a mixture of embedding a browser (Galeon) and messing with the document content in a scripting language (Greasemonkey).

So, nothing new under the sun, but one more way of doing the same that may be more convenient in some occasions.

In Sugar, the single reason why we cooked our own solution is so the user can study the code of our browser and make modifications to it as easily as possible (freedom 3). We don't want the user to just 'use' the software we provide and to calmly wait for the next release, but we want them to 'create' new tools based on what we provide.

If we had kept using gtkmozembed, our browser would have had a bigger proportion of C/C++ code (less easy to study and modify) and would have mixed javascript and python (more effort required to study and modify).

At the end of the day, Sugar is not one more productivity desktop, but a learning platform. And in the same way that each individual learns in his/her own way, they need to be able to suit their learning tools to their learning habits.

Perhaps not everybody that uses Sugar will learn to code, but at least those people that have the inclination to write small amounts of code (spreadsheet macros, for example) will be able to add a button there, transform the document viewed, etc. And then share it with their friends.

Embedding Mozilla

To finish this series on embedding existing GNOME stuff in new apps, this is one of the design mockups of the browser in Sugar:


We are implementing it with Mozilla for now (though would love to have an alternative in WebKit as well, code welcome) and after some time using gtkmozembed, Marco decided that we would be better off with something lighter (read less buggy), with less amount of C code and with easy access to PyXPCOM. Then hulahop was born.

This is the simplest snippet that will bring you an embedded instance of mozilla into your pygtk app:

import os

import gobject
gobject.threads_init()
import gtk

import hulahop
hulahop.startup(os.path.expanduser('~/.hulahop_test_profile'))
from hulahop.webview import WebView

w = gtk.Window()
w.show()

v = WebView()
w.add(v)
v.show()

v.load_uri('http://planet.gnome.org')

gtk.main()

But that isn't anything that gtkmozembed cannot do, so if you add the following snippet just before the call to gtk.main(), you will get something more interesting ;)

import xpcom
from xpcom.components import interfaces

class ProgressListener(object):
    _com_interfaces_ = interfaces.nsIWebProgressListener

    def onStateChange(self, webProgress, request, stateFlags, status):
        if not (stateFlags & interfaces.nsIWebProgressListener.STATE_IS_NETWORK and \
                stateFlags & interfaces.nsIWebProgressListener.STATE_STOP):
            return

        images = v.dom_window.document.documentElement.getElementsByTagName('IMG')
        for i in range(images.length):
            image = images.item(i)
            if image.src.startswith('http://planet.gnome.org/heads'):
                image.height *= 3
                image.width /= 3

listener = ProgressListener()
wrapped_listener = xpcom.server.WrapObject(listener,
                                           interfaces.nsIWebProgressListener)
v.web_progress.addProgressListener(wrapped_listener,
                                   interfaces.nsIWebProgress.NOTIFY_STATE_ALL)

As you can see, with hulahop you have ready access to most mozilla internals, in the example above we are manipulating the document DOM, but you can also access network stuff, security, user events, etc

Right now, those snippets will work only on Fedora 10 unless you build your own stuff. But as in the abiword case, people are already working on packaging hulahop for all the major distros.

And what about the future? I would love to see more applications to provide their canvases as proper gtk widgets and moving them to libraries. The ones on the top of my list are gnumeric and inkscape, any suggestion?

Embedding abiword

After yesterdays bit about how really soon we'll be able to easily embed evince in any gtk app, today is abiword's turn.

This is the UI that Eben designed for the Write activity in Sugar:



And this is one of the quickest ways to embed abiword using python:


from abiword import Canvas
import gtk

w = gtk.Window()
w.show()

c = Canvas()
w.add(c)
c.show()

gtk.main()


If you are curious about what you can do programaticaly with that Canvas instance, just type pydoc abiword.Canvas.

The only distros I know where this snippet should work are Fedora 10 and 11, but there are already some beautiful souls in #sugar who are working to make sure that it will be available in the next releases of Ubuntu, Debian, Mandriva, Gentoo, OpenSUSE and others.

Update: more and better info about PyAbiword here.

Embedding Evince, GNOME Mobile and GNOME 4.0

Evince gets embeddable

The fine evince hackers, with special mention to Carlos Garcia Campos, have been of great help during the last week as I was trying to get upstreamed our sugar-evince fork.

Sugar had to modify Evince so we could link python programs against it and build the intended user experience, quite different from that in GNOME. Several people (Marco Pesenti Gritti, Reinier Heeres and Daniel Drake) had worked on it during the last two years, though in the rush to ship a complete learning environment, never got to upstream the changes. Check out the design mockup by Eben Eliason of our document viewer:


So Evince 2.25.5 is going to ship with libevview and I'm going to ask for an exception of the API freeze so we can get the python bindings in the next release of gnome-python-desktop. Then you will be able to write something like this and get your own document viewer:

import evince
import gtk

w = gtk.Window()
w.show()

e = evince.View()
w.add(e)
e.show()

document = evince.factory_get_document('file:///home/tomeu/Desktop/comic.pdf')
e.set_document(document)

gtk.main()


What has this to do with GNOME Mobile?

GNOME Mobile is a platform for other people to build their own software on. Most of the solutions that people base on GNOME Mobile will be able to run unmodified GNOME applications, but given hardware constraints or different intended user experiences that won't happen too often.

Platforms like Maemo have had to maintain their fork of Evince and apply patches to it so they can provide a document viewer that conforms to the Hildon UI guidelines. I can only guess that this is very expensive for Nokia, and what about other vendors interested in basing their software on GNOME Mobile? Will they have the resources needed to maintain forks of all the GNOME applications they wish to reuse?

So I hope other people will feel attracted by the advantages of exposing widgets out of apps and we can work together so as time passes more and more GNOME apps can be embedded and new UIs get built around them.

And GNOME 4.0?

I have no idea what GNOME 4.0 will be, but I know that lots of people (and organizations) in the GNOME world are not resigning themselves to build a Windows-clone and are willing to explore new user experiences that help computing to bring more benefits to more people.

By splitting base functionality to shared libraries and making easier to build new UIs around them, we have a better base on which to play and experiment, until the day will come ;)

Upstreaming the evince changes

The other day in #sugar happened a little conversation that left me quite a bit worried. Turns out that in order to have distros shipping a working pdf reader (Read) in Sugar, we need first to upstream changes we did a couple years ago and have been periodically rebasing.

As OLPC isn't the only kid playing in SugarLand any more, we really really need to have distros to ship a minimally complete Sugar environment in their next releases in a couple of months from now.

So started the upstream process and any help is more than welcome: http://sugarlabs.org/go/Evince

What I've been up since the last post

Haven't had much time to blog because of the holidays and the imminent feature freeze on Jan 16th.

So here comes a summary of what I have been up to since the last post on Dec 20th:

• Review and push Ryan Kabir's work on moving some actions from the palette of the big XO icon in the favorites view to the frame, so it's always accessible regardless of which view you are in:
  
  


• Kept working on the file transfer UI, lots of polish is still needed


• Added an utility class (util.TempFilePath) that hopefully will remove the temp file leaks we have been suffering in past releases


• Bunch of bugfixing, specially in the journal: #36, #38, #126, #131, #132, #165, #3060


• Lots of work on removable devices in the journal. It should be pretty much usable now without using an index nor ever writing to the device. Performance isn't too bad and it's near to be feature complete


• Change the favorites view to display the last entries for every activity and resume by default when the icon is clicked. There's still quite a bit of work to do in order to not confuse people, specially hint more strongly about naming activities.