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!
Thursday, March 19, 2009
Wednesday, February 18, 2009
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!
Also, note that you can now upload screenshots of your activity, see the "Edit previews" link in the editing options.
Thanks!
Tuesday, February 17, 2009
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:
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.
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.
Monday, February 2, 2009
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.
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.
Tuesday, January 27, 2009
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.
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.
> 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.
Monday, January 26, 2009
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:
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 ;)
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?

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?
Subscribe to:
Posts (Atom)