Looks like we are almost ready for one more push to Python development in GNOME 3, as originally announced by J5.
From 17th to 21th of January we'll be gathering at the brmlab hackerspace in Prague to hack on the applications of the brave souls that are taking the lead and port them to the future: Gtk+ 3, Python 3 and introspection.
We are having several GNOME volunteers, and Canonical, Collabora, OLPC, openSUSE and Red Hat are sending their people to lend a hand.
If you think you should be there, please act quickly and add your name to the wiki before J5 secures the budget. If you would like to contribute to the funds or in any other way that would help this hackfest become a success, please send email to the GNOME Foundation board.
Friday, December 3, 2010
Wednesday, October 27, 2010
The cost of doing your own shell on top of GNOME
In this post, Dave Neary writes:
Just wanted to mention that the Sugar team never had more than 4 full-time paid developers (and most of the time far less than that), and this is relevant to this discussion because shows that with the right approach and knowledge in the team, the challenge doesn't need to be so insurmountable. As a comparison, I would be very surprised if the other GNOME-based shells mentioned would have had teams with less than a few dozens of engineers.
Now, Sugar as a project and its architecture were set up by the Desktop Team at Red Hat, composed by long-time and well-known GNOME hackers, of which most of them are now involved in the GNOME Shell, maybe not by chance.
With this I want to say that maybe Canonical has in their Unity team people with equivalent experience, who have shaped the GNOME project since its inception and thus know how to take this challenge. If that's the case, then I think they would have a bigger chance than what Dave concedes.
OLPC had many teething problems with the Sugar desktop environment. Bugs, stability and performance issues plagued the project for many months, to the point where they abandoned the development of the stack as the primary target platform for the devices. The project lives on in Sugar Labs, thans to a broad and vibrant developer community.-- snip --
There is another possibility which seems to me more plausible: building a rock solid and functional desktop is hard. Really hard.
Just wanted to mention that the Sugar team never had more than 4 full-time paid developers (and most of the time far less than that), and this is relevant to this discussion because shows that with the right approach and knowledge in the team, the challenge doesn't need to be so insurmountable. As a comparison, I would be very surprised if the other GNOME-based shells mentioned would have had teams with less than a few dozens of engineers.
Now, Sugar as a project and its architecture were set up by the Desktop Team at Red Hat, composed by long-time and well-known GNOME hackers, of which most of them are now involved in the GNOME Shell, maybe not by chance.
With this I want to say that maybe Canonical has in their Unity team people with equivalent experience, who have shaped the GNOME project since its inception and thus know how to take this challenge. If that's the case, then I think they would have a bigger chance than what Dave concedes.
Friday, October 22, 2010
Now moving for real
In January I tried to move from Sugar to other projects, but Collabora prevented it by hiring me to work on Sugar and Telepathy integration.
Nine months and a release cycle later, I'm doing it for real. During the next months I will be switching to work on totally different stuff, involving Clutter and WebKit hacking.
Also plan to keep hacking a bit on Telepathy, would be a pity stop using what I learned during most of this year.
Nine months and a release cycle later, I'm doing it for real. During the next months I will be switching to work on totally different stuff, involving Clutter and WebKit hacking.
Also plan to keep hacking a bit on Telepathy, would be a pity stop using what I learned during most of this year.
Tuesday, October 5, 2010
Notes on porting a Python application to GNOME 3
For you, GNOME Planet readers, Jordi is porting Naufrago! from PyGTK to GNOME 3 (so PyGObject + introspection) and has posted in his blog some notes that will help others doing the same.
Monday, October 4, 2010
Lost email
My email client just permanently deleted a message marked as spam before I could open it, but had time to glance the subject line and it seemed to be a request for contacts in LatAm related to the OLPC deployments there.
So if the person who sent it is reading this, just send it again.
So if the person who sent it is reading this, just send it again.
Friday, October 1, 2010
Get the latest PyGObject and introspection bits!
So people are starting to port their apps to introspection from the about-to-be-obsolete PyGtk+ bindings and I'm getting questions in #python @ GIMPNet about how to get the latest and greatest version without having to build stuff.
For those in Fedora: you can get it already from F15, will be backported to F14 after it's out.
For those in Debian: watch experimental for updated packages soon.
For those in Ubuntu: update to Maverick and watch the telepathy PPA for updated packages soon.
Update from comments:
For those in openSUSE: you can get it already from openSUSE Factory, and will be backported to 11.3 as part of the GNOME 2.32 backport.
For those in Microsoft Windows: no binary packages have been built at this moment and nobody is currently known to be working on it.
If anybody has corrections or additions, please comment and I will update the main post.
For those in Fedora: you can get it already from F15, will be backported to F14 after it's out.
For those in Debian: watch experimental for updated packages soon.
For those in Ubuntu: update to Maverick and watch the telepathy PPA for updated packages soon.
Update from comments:
For those in openSUSE: you can get it already from openSUSE Factory, and will be backported to 11.3 as part of the GNOME 2.32 backport.
For those in Microsoft Windows: no binary packages have been built at this moment and nobody is currently known to be working on it.
If anybody has corrections or additions, please comment and I will update the main post.
Monday, September 20, 2010
Plans for the next cycle
So it's that time of the ½ year when one starts to think on what to spend his next months. Of course it will depend on what my employer thinks it's best, but this is what I'm thinking right now.
Port Sugar to telepathy-glib: right now Sugar uses Telepathy via python-dbus, which is a quite low level API. The code could get considerably shorter and simpler by using the higher level API in telepathy-glib. For that, we would need to use gobject-introspection because there are no plans for static bindings for Python.
Expose extended contact attributes through an official addition to telepathy-spec: Right now Sugar is using an extension to telepathy-salut and telepathy-gabble for discovering additional information about the online contacts. In our effort to make Sugar a regular Telepathy user and reducing the maintenance burden of such extensions, we should move to use only official additions to telepathy-spec.
Expose activities through an official addition to telepathy-spec: In Sugar you can discover which activities are being publicly shared by your contacts, join them and also send and receive private invites. This is basically announcing which applications running in your desktop have collaboration capabilities by means of IM channels. Same as above, we need to move to use interfaces of more general use.
Port Sugar to GNOME 3: Sugar's cycle is synchronized with GNOME, Fedora and Ubuntu so each release can be more easily packaged and delivered by distros. Though Gtk+2 and Gtk+3 are installable in parallel, the lamentable state in which the stable Python GNOME bindings are means nobody is there to maintain all the bindings and much less for wrapping new APIs such as GSettings. For the sake of moving along with our platform, we'll have to port Sugar and all the activities to GNOME 3 through with gobject-introspection. PyGObject is very close to have feature-complete support for introspection but still will take quite a bit of work to make it stable.
Port Sugar to telepathy-glib: right now Sugar uses Telepathy via python-dbus, which is a quite low level API. The code could get considerably shorter and simpler by using the higher level API in telepathy-glib. For that, we would need to use gobject-introspection because there are no plans for static bindings for Python.
Expose extended contact attributes through an official addition to telepathy-spec: Right now Sugar is using an extension to telepathy-salut and telepathy-gabble for discovering additional information about the online contacts. In our effort to make Sugar a regular Telepathy user and reducing the maintenance burden of such extensions, we should move to use only official additions to telepathy-spec.
Expose activities through an official addition to telepathy-spec: In Sugar you can discover which activities are being publicly shared by your contacts, join them and also send and receive private invites. This is basically announcing which applications running in your desktop have collaboration capabilities by means of IM channels. Same as above, we need to move to use interfaces of more general use.
Port Sugar to GNOME 3: Sugar's cycle is synchronized with GNOME, Fedora and Ubuntu so each release can be more easily packaged and delivered by distros. Though Gtk+2 and Gtk+3 are installable in parallel, the lamentable state in which the stable Python GNOME bindings are means nobody is there to maintain all the bindings and much less for wrapping new APIs such as GSettings. For the sake of moving along with our platform, we'll have to port Sugar and all the activities to GNOME 3 through with gobject-introspection. PyGObject is very close to have feature-complete support for introspection but still will take quite a bit of work to make it stable.
Talk about Sugar in Software Freedom Kosova 2010 Conference
FLOSSK has invited me to talk about Sugar in the upcoming Software Freedom Kosova 2010 Conference that will take place next weekend (25th-26th September) in Prishtina.
Will be a general presentation of Sugar but if you are attending I will be happy to chat as well about any other subjects related to free software, GNOME, Python, etc.
Will be a general presentation of Sugar but if you are attending I will be happy to chat as well about any other subjects related to free software, GNOME, Python, etc.
Friday, September 10, 2010
Fetching patches from GMail
We are experimenting in Sugar with moving to a patch workflow closer to that of the Linux kernel, until know we have been tracking tickets in trac.
Since I still haven't managed to drop GMail because of how its conversations feature make so efficient to read mailing lists, I had been copy & pasting the unformatted patches, be them inline in the message or as attachments.
There's clearly quite a bit of room for optimization and after being so spoiled by git-bz (thanks Owen!) and failing to find something close enough to what I wanted, I decided to take this script and adapt it to my workflow.
It's working quite well for just fetching patches from GMail and I'm already thinking of adding some features such as suggesting Reviewed-by and Test-by tags, and closing the associated trac ticket. It would be cool as well to automate a bit patch reviews so I can do it from the command line without having to use another full-fledged mail client. I'm also considering dropping libgmail and move to POP and/or IMAP.
Here is the code in case it's of use to anyone else.
Thanks to Ted Kulp for the initial script.
Since I still haven't managed to drop GMail because of how its conversations feature make so efficient to read mailing lists, I had been copy & pasting the unformatted patches, be them inline in the message or as attachments.
There's clearly quite a bit of room for optimization and after being so spoiled by git-bz (thanks Owen!) and failing to find something close enough to what I wanted, I decided to take this script and adapt it to my workflow.
It's working quite well for just fetching patches from GMail and I'm already thinking of adding some features such as suggesting Reviewed-by and Test-by tags, and closing the associated trac ticket. It would be cool as well to automate a bit patch reviews so I can do it from the command line without having to use another full-fledged mail client. I'm also considering dropping libgmail and move to POP and/or IMAP.
Here is the code in case it's of use to anyone else.
Thanks to Ted Kulp for the initial script.
Tuesday, September 7, 2010
Open GNOME/Sugar position in Greece
A group of people passionate about improving education is working on implementing OLPC and Sugar technologies in Greece and they have an open position for someone with GNOME knowledge.
This is an excellent opportunity to hack on free software, improve educational opportunities in your country and get paid for it. These are the areas of work identified to date:
Sugar is closely based on GNOME and is mostly written in Python. The job will require working within upstream communities and contributing back.
If you are interested, contact Thanasis Priftis @ thanasis.priftis at gmail.com
This is an excellent opportunity to hack on free software, improve educational opportunities in your country and get paid for it. These are the areas of work identified to date:
1. Better localisation of Sugar and Sugar activities. This would involve Sugar enhancements such as:
* spell checking facilities all around the platform
* sugar-wide dictionary
* new pedagogical activities (i.e. an activity that helps children with dyslexia)
2. Sensors and based on existing platforms (scratch) or creating musical activities using sensors (or enhancing TamTam).
3. Repackaging wikipedia, in order to include various Balkan language resources. Probably adding further material (ex, index of Internet archive or Gutenberg project)
Sugar is closely based on GNOME and is mostly written in Python. The job will require working within upstream communities and contributing back.
If you are interested, contact Thanasis Priftis @ thanasis.priftis at gmail.com
Wednesday, August 11, 2010
PyGObject matching GLib version numbers
John Stowers has proposed to change the PyGObject numbering scheme to match that of GLib:
http://mail.gnome.org/archives/python-hackers-list/2010-August/msg00006.html
If anybody has a problem with this, please speak up now. Otherwise the next unstable release of PyGObject will be 2.25.1.
http://mail.gnome.org/archives/python-hackers-list/2010-August/msg00006.html
If anybody has a problem with this, please speak up now. Otherwise the next unstable release of PyGObject will be 2.25.1.
Sunday, July 18, 2010
GNOME beer event in Prague
With occasion of the visit to Prague of several GNOME colleagues, we have decided to get together for some beers this tuesday July 20th at U slovanske lipy, starting at about 19.00. You have a review in english here and please comment in this blog if you plan to come so we can better organize.
Thursday, July 8, 2010
Python and introspection are in Fedora
Colin Walters updated PyGObject in Rawhide to 2.21.4 and thus you can start using libraries with introspection support from Python without having to build anything yourself. One step closer to GNOME apps in Python 3.x!
If an interested Fedora packager is reading this, would be nice to split the _gi_cairo.so module to its own rpm so PyGObject itself drops again the dependency on PyCairo.
If an interested Fedora packager is reading this, would be nice to split the _gi_cairo.so module to its own rpm so PyGObject itself drops again the dependency on PyCairo.
Tuesday, June 29, 2010
New PyGObject release: 2.21.4
Just made a new release of PyGObject, this is the first one that includes introspection support after merging PyGI. That means that you can now call GObject-based libraries from Python without requiring specific Python bindings, just the .typelib files that should be already packaged along the shared library.
Next challenge: Python 3.x support.
Announcement follows:
Next challenge: Python 3.x support.
Announcement follows:
Hi,
I am pleased to announce version 2.21.4 of the Python bindings for GObject.
The new release is available from ftp.gnome.org as and its mirrors as
soon as its synced correctly:
http://download.gnome.org/sources/pygobject/2.21/
What's new since PyGObject 2.21.3?
- Build the cairo shim as a python module so the _gi module
stops linking to it (Tomeu Vizoso)
- add drawing area demo (John (J5) Palmieri)
- sort the demo list (John (J5) Palmieri)
- rename iter to treeiter so we aren't using a python reserved
word (John (J5) Palmieri)
- Fixup for change in buffer API (John (J5) Palmieri)
- add ListStore, TreeStore and TreeViewColumn APIs (John (J5) Palmieri)
- Add unit test for add_actions user data. (Ignacio Casal Quinteiro)
- Pass user_data param when adding actions (Paolo Borelli)
- add an exception type to the try/except block (John (J5) Palmieri)
- return PyList instead of PyTuple for array, return empty
list for NULL arrays (John (J5) Palmieri)
- Fix 'make distcheck' (Tomeu Vizoso)
- Allow building pygobject without introspection support by
providing --disable-introspection to configure. (Tomeu Vizoso)
- Make sure that sys.argv is a list and not a sequence. (Tomeu Vizoso)
- Force loading the GObject typelib so we have available the
wrappers for base classes such as GInitiallyUnowned. (Tomeu Vizoso)
- we shouldn't g_array_free NULL pointers (John (J5) Palmieri)
- remove unneeded TextIter creation in the tests (John (J5) Palmieri)
- add override for TextBuffer (John (J5) Palmieri)
- fix up some build issues (John (J5) Palmieri)
- make the overrides file git friendly by appending to __all__
after each override (John (J5) Palmieri)
- Override Dialog constructor and add_buttons method (Paolo Borelli)
- Merge PyGI (Johan Dahlin)
Note to packagers:
The configure option --enable-pygi has been removed and we build now
introspection support by default. It's not recommend for distros, but
if needed, you can build PyGObject without requiring
gobject-introspection by passing --disable-introspection. When built
with introspection support (the default) we require pycairo as a build
dependency. We now install one more python module _gi_cairo.so that
links to libcairo and depends on pycairo and that should be packaged
separately.
Blurb:
GObject is an object system library used by GTK+ and GStreamer.
PyGObject provides a convenient wrapper for the GObject library for use
in Python programs, and takes care of many of the boring details such as
managing memory and type casting. When combined with PyGTK, and
gnome-python, it can be used to write full featured Gnome applications.
Like the GObject library itself PyGObject is licensed under the
GNU LGPL, so is suitable for use in both free software and proprietary
applications. It is already in use in many applications ranging
from small single purpose scripts up to large full
featured applications.
PyGObject requires glib >= 2.22.4 and Python >= 2.3.5 to build.
GIO bindings require glib >= 2.22.4.
Please remember that this is an unstable release and shouldn't be used
in production.
Regards,
The PyGObject team
Monday, June 28, 2010
PyGI has been merged into PyGObject
Last week the people hacking on introspection support for PyGObject decided to merge (again) PyGI into PyGObject.
As soon as the patches in this bug get reviewed and pushed, I will be making a new release of PyGObject that will include introspection support.
For packagers, this means that PyGI packages can be dropped and that future releases of PyGObject will depend on introspection. The release notes will contain more specific information for packagers.
The 'pygi' component in bugzilla has been closed for new bugs and we are using component 'introspection' in the product 'pygobject'.
Similarly, the #pygi channel at GIMPNet has been changed to invite-only and we have registered the #python channel for all matters related to the internals of Python on GNOME. For user questions, please keep using #pygtk also on GIMPNet.
We need help updating the wiki to reduce the confusion caused by the brief but tribulated life of PyGI, at least we are certain that it has finally found its permanent home.
We hope that users of Python on GNOME will appreciate what introspection brings to our platform and also that from now on it will be more accessible to everybody.
As soon as the patches in this bug get reviewed and pushed, I will be making a new release of PyGObject that will include introspection support.
For packagers, this means that PyGI packages can be dropped and that future releases of PyGObject will depend on introspection. The release notes will contain more specific information for packagers.
The 'pygi' component in bugzilla has been closed for new bugs and we are using component 'introspection' in the product 'pygobject'.
Similarly, the #pygi channel at GIMPNet has been changed to invite-only and we have registered the #python channel for all matters related to the internals of Python on GNOME. For user questions, please keep using #pygtk also on GIMPNet.
We need help updating the wiki to reduce the confusion caused by the brief but tribulated life of PyGI, at least we are certain that it has finally found its permanent home.
We hope that users of Python on GNOME will appreciate what introspection brings to our platform and also that from now on it will be more accessible to everybody.
Saturday, June 19, 2010
Proposed GNOME goal: Port your PyGTK to the new PyGI bindings
Javier Jardón has proposed this goal, which hopefully will make more prominent the convenience of starting to port your app from the old APIs as soon as possible.
If we fail to get a solid Python story in GNOME 3.0, it will be much more painful to do the porting in subsequent GNOME 3.x releases.
We still need many more people starting to port their apps and filing bugs (even better with patches!). And before you think it's too soon, read this bugzilla comment:
So we aren't perfect yet, but we're already useful and fast.
As an aside, I have heard through the grapevine that during GUADEC 2010 several people will meet to hack on introspection and PyGI. So if you want to have some of the PyGI hackers in the same room when you port your app, keep an eye on this and J5's blog for updates.
Thanks to Collabora for sponsoring my presence in GUADEC and to all the people who are working to make it possible.
If we fail to get a solid Python story in GNOME 3.0, it will be much more painful to do the porting in subsequent GNOME 3.x releases.
We still need many more people starting to port their apps and filing bugs (even better with patches!). And before you think it's too soon, read this bugzilla comment:
My app is a complex pygtk
program and with some, small change now is running with pygi,
i have errors in parts like "event.type == gtk.gdk.KEY_PRESS " or
actionGroup = gtk.ActionGroup("Actions")
but is running fast almost perfectly.
So we aren't perfect yet, but we're already useful and fast.
As an aside, I have heard through the grapevine that during GUADEC 2010 several people will meet to hack on introspection and PyGI. So if you want to have some of the PyGI hackers in the same room when you port your app, keep an eye on this and J5's blog for updates.
Thanks to Collabora for sponsoring my presence in GUADEC and to all the people who are working to make it possible.
Friday, June 11, 2010
New PyGObject unstable release: 2.21.2
PyGObject has seen a new release, see the announcement below.
I have started lending a hand to Gian Mario with the release but we are still very short-handed. If you care about Python and GNOME and know a bit of C and Python, please consider helping with patch reviews and general patch herding:
https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=pygobject&patch-status=none
I have started lending a hand to Gian Mario with the release but we are still very short-handed. If you care about Python and GNOME and know a bit of C and Python, please consider helping with patch reviews and general patch herding:
https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=pygobject&patch-status=none
Hi,
I am pleased to announce version 2.21.2 of the Python bindings for GObject.
The new release is available from ftp.gnome.org as and its mirrors
as soon as its synced correctly:
http://download.gnome.org/sources/pygobject/2.21/
What's new since PyGObject 2.21.1?
- Drop sinkfuncs. (Tomeu Vizoso)
- Clear error if we failed the import (Colin Walters)
- Added missing , to keyword list of gio.GFile.set_attribute
(John Ehresman)
- Fix arg conversion in gio.GFile.set_attribute (John Ehresman)
- Set constants under python 2.5 or before (John Ehresman)
- Doc Extractor: Use replacements that make sense for &...;
expressions. (José Alburquerque)
- Add build docs for windows (John Stowers)
- Setup.py cosmetic tidy (John Stowers)
- Fix crash when importing gio (John Stowers)
- Bug 589671 - Dont use generate-constants (John Stowers)
- Bug 589671 - Fix setup.py for windows build (John Stowers)
- Include pygsource.h (John Stowers)
- codegen/docextract_to_xml.py: One more &...; replacement
( ). (José Alburquerque)
- codegen/docextract_to_xml.py: Replace some &..; that cause
errors. (José Alburquerque)
- codegen/docextract_to_xml.py: Handle C++ multi-line comments.
(José Alburquerque)
- codegen/docextract.py: Stop final section processing on first
match. (José Alburquerque)
- Update doc extraction tool to handle GObjectIntrospection
annotations. (José Alburquerque)
- Docs: replace gio.IO_ERROR_* with gio.ERROR_* (Paul Bolle)
- Bug 613341 - pygobject tests seem to require pygtk causing a
circular (Gian Mario)
- Don't raise an error in _pygi_import if pygi support is
disabled (Simon van der Linden)
- Initialize PyGPollFD_Type.fd_obj to NULL (Tomeu Vizoso)
- Bug 605937 - pygobject: Makefile.am sets $TMPDIR, disrupting
distcc (Gian Mario)
- Wrap gio.Cancellable.make_pollfd() and add a test (Gian Mario)
- Make cancellable an optional parameter in many methods (Gian
Mario)
Blurb:
GObject is a object system library used by GTK+ and GStreamer.
PyGObject provides a convenient wrapper for the GObject library for use
in Python programs, and takes care of many of the boring details such as
managing memory and type casting. When combined with PyGTK, PyORBit and
gnome-python, it can be used to write full featured Gnome applications.
Like the GObject library itself PyGObject is licensed under the
GNU LGPL, so is suitable for use in both free software and proprietary
applications. It is already in use in many applications ranging
from small single purpose scripts up to large full
featured applications.
PyGObject requires glib >= 2.22.4 and Python >= 2.3.5 to build.
GIO bindings require glib >= 2.22.4.
Please remember that this is an unstable release and shouldn't be used
in production.
Regards,
The PyGObject team
Monday, June 7, 2010
PyGI now in Debian and Ubuntu
Thanks to the Debian GNOME Team, Laurent Bigonville and Canonical's Robert Ancell, PyGI is well on its way to Debian and Ubuntu:
http://packages.debian.org/sid/python-gi
https://launchpad.net/debian/+source/pygi/0.5.1-1
Thanks to everybody involved in this effort, upstream developers appreciate your work!
http://packages.debian.org/sid/python-gi
https://launchpad.net/debian/+source/pygi/0.5.1-1
Thanks to everybody involved in this effort, upstream developers appreciate your work!
Friday, June 4, 2010
New PyGI release: 0.6.0
PyGI has seen a new release, follows the announcement:
Hi all,
this new release brings several new features and bug fixes and we feel application authors will have an easier time porting their software to use introspection. To mark this usability milestone we have started the 0.6.x series.
Apart from further feature and stability work, you can expect compatibility with Python 3.x in a future 0.6.x release.
http://ftp.gnome.org/pub/GNOME/sources/pygi/0.6/pygi-0.6.0.tar.gz
This release adds a dependency on gobject-introspection 0.6.14 or newer.
== Changes ==
* Added overrides for better compatibility with the old API:
GtkUIManager and GtkActionGroup
* Improved callback support
* Support for G*Array arguments
* Support for caller-allocates
== Join the effort! ==
Any feedback is welcome and the PyGI community will be happy to assist any porting efforts in the mailing lists mentioned below, in the #pygi IRC channel in Freenode and in GNOME's bugzilla:
Internals development mailing list:
http://mail.gnome.org/mailman/listinfo/python-hackers-list
Application development mailing list:
http://www.daa.com.au/mailman/listinfo/pygtk
Known issues: https://bugzilla.gnome.org/buglist.cgi?product=pygi&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&version=unspecified
Enter a new report: https://bugzilla.gnome.org/enter_bug.cgi?product=pygi
Main wiki page: http://live.gnome.org/PyGI
Regards,
Tomeu
--
John (J5) Palmieri (10)
* support for caller-allocates annotations for structs
* don't import gobject directly in the tests
* fix up Builder override, add new override methods, and add unit tests
* check refcounting of callback userdata in unit tests
* correctly handle floating objects in gtk
* Return an empty list when a NULL GList and GSList is returned
* fix NULL array unit tests and fix crasher when sending None as an array
* don't error out on methods with callbacks as return type
* reset sys.argv to the return value of Gtk.init_check
* add GtkUIManager and GtkActionGroup overrides
Steve Frécinaux
Hi all,
this new release brings several new features and bug fixes and we feel application authors will have an easier time porting their software to use introspection. To mark this usability milestone we have started the 0.6.x series.
Apart from further feature and stability work, you can expect compatibility with Python 3.x in a future 0.6.x release.
http://ftp.gnome.org/pub/GNOME/sources/pygi/0.6/pygi-0.6.0.tar.gz
This release adds a dependency on gobject-introspection 0.6.14 or newer.
== Changes ==
* Added overrides for better compatibility with the old API:
GtkUIManager and GtkActionGroup
* Improved callback support
* Support for G*Array arguments
* Support for caller-allocates
== Join the effort! ==
Any feedback is welcome and the PyGI community will be happy to assist any porting efforts in the mailing lists mentioned below, in the #pygi IRC channel in Freenode and in GNOME's bugzilla:
Internals development mailing list:
http://mail.gnome.org/mailman/listinfo/python-hackers-list
Application development mailing list:
http://www.daa.com.au/mailman/listinfo/pygtk
Known issues: https://bugzilla.gnome.org/buglist.cgi?product=pygi&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&version=unspecified
Enter a new report: https://bugzilla.gnome.org/enter_bug.cgi?product=pygi
Main wiki page: http://live.gnome.org/PyGI
Regards,
Tomeu
--
John (J5) Palmieri
* support for caller-allocates annotations for structs
* don't import gobject directly in the tests
* fix up Builder override, add new override methods, and add unit tests
* check refcounting of callback userdata in unit tests
* correctly handle floating objects in gtk
* Return an empty list when a NULL GList and GSList is returned
* fix NULL array unit tests and fix crasher when sending None as an array
* don't error out on methods with callbacks as return type
* reset sys.argv to the return value of Gtk.init_check
* add GtkUIManager and GtkActionGroup overrides
Steve Frécinaux
(1)
* Fix warning in configure.
Tomeu Vizoso (12)
* Pre-release version bump 0.6.0
* Wrap C arrays in structs as GArrays before converting to Python
* Install pre-commit hook that checks the code changes for style conformance
* Apply consistent whitespace formatting with:
* Prepend gi.repository to the __module__ attribute of wrapper classes.
* Correctly identify at creation time:
* Dont complain if another base has implemented the method
* Improve handling of subclasses without __gtype_name__
* Add support for out args in callbacks
* Add support for GArray args
* GTypeInterface cannot be unrefed
* If None is passed to an interface which takes an object, convert it to NULL
Tuesday, May 25, 2010
New Python list at gnome.org
One of the action items that came out of the UDS sessions that touched introspection was to create an appropriate list for discussing the transition to introspection and Python 3.x.
The list description should make clear why any of the existing lists was deemed a good fit:
So if you are worried about how your GNOME apps written in Python are going to transition to GNOME 3.x and Python 3.x, join us before it's too late!
http://mail.gnome.org/mailman/listinfo/python-hackers-list
The list description should make clear why any of the existing lists was deemed a good fit:
Development of Python bindings
Note:
* it's for the implementation details and you need to know C, not Python
* questions about the internals are on-topic, even if you're not developing the internals themselves
* it's a single place to discuss pygtk, pygi, pygobject wrapper implementations
So if you are worried about how your GNOME apps written in Python are going to transition to GNOME 3.x and Python 3.x, join us before it's too late!
http://mail.gnome.org/mailman/listinfo/python-hackers-list
Monday, May 17, 2010
Telepathy and Ubuntu
As mentioned in my last post about the Ubuntu Developer Summit last week, there's interest in Ubuntu for using the Telepathy framework in more of their projects. There was discussion of using Telepathy in their telephony stack and also on some Ubuntu-specific changes in Empathy, but I was most interested in their effort to make easy and fun to code collaborative applications.
As part of the work on Sugar that Collabora is sponsoring, I also have a big interest in making as easy as possible to use the telepathy framework, be it in applications or in desktop components such as the Sugar shell.
For now, I'm going to help kickstart the process by implementing some toy-like API on top of Telepathy in the form of widgets for Quickly, here is the branch.
This is what we came up with in the brainstorming session about the "easy and fun" API:
As PyGI is not packaged yet for Ubuntu and for the sake of getting started quickly, I'm going to do the initial implementation with the old telepathy-python bindings, but I hope that whatever gets into the Maverick release uses the much nicer telepathy-glib API through introspection.
Also will be trying to keep an eye on the collaboration needs of Sugar activities so more people benefit from this effort.
As part of the work on Sugar that Collabora is sponsoring, I also have a big interest in making as easy as possible to use the telepathy framework, be it in applications or in desktop components such as the Sugar shell.
For now, I'm going to help kickstart the process by implementing some toy-like API on top of Telepathy in the form of widgets for Quickly, here is the branch.
This is what we came up with in the brainstorming session about the "easy and fun" API:
class Client(Boo):
def __init__(self):
self.tube_handler = MessageTubeHandler("tubey")
self.tube_handler.connect("handle-channel", self.on_handle_channel)
def on_handle_channel(self, tube):
self.image_tube = tube
tube.connect("message-received", self.on_message_received)
def on_message_received(self, tube, msg):
if "img_url" in msg:
self._download_image(msg["img_url"])
def on_contact_selected(self, contact, account):
self.image_tube = tp.MessageTube(contact, account)
msg = {}
msg["note"] = self.label1.get_text()
self.image_tube.send(msg)
def on_tube_initiated(self, tube):
if "kenvandine" in tube.contact.props.identifier:
return
As PyGI is not packaged yet for Ubuntu and for the sake of getting started quickly, I'm going to do the initial implementation with the old telepathy-python bindings, but I hope that whatever gets into the Maverick release uses the much nicer telepathy-glib API through introspection.
Also will be trying to keep an eye on the collaboration needs of Sugar activities so more people benefit from this effort.
Ubuntu and GObject introspection
Canonical invited me to spend last week in Brussels at the Ubuntu Developer Summit, representing the upstream projects I'm part of: Telepathy, GNOME and Sugar.
On the GNOME front, I tried to understand Ubuntu plans regarding introspection and developing with Python. At the beginning I was very concerned because the developers I talked to didn't seemed to be aware of the changes that introspection would bring to GNOME and thus hadn't any strategy in place.
The most notable effect of the appearance of introspection support in GNOME is that the existing static bindings for Python and other languages will stop being maintained and no new bindings will be developed for new APIs. For downstreams such as Ubuntu this means that they will either have to maintain and develop static bindings themselves alone, or move to use introspection. See here for an explanation of how apps in python would use introspection to call GObject C code.
If Ubuntu limited itself to package whatever software upstream releases, they could just sit waiting for new releases and update the dependencies accordingly. But turns out they produce a lot of Python code themselves and thus need to get involved in this transition for their own good. They also have the goal of being a great platform for developing desktop apps with Python, and introspection will play a major role in that.
Jorge Castro was tremendously helpful by presenting myself to Barry Warsaw, who has a responsibility role in Ubuntu's use of Python. Barry has been working on the transition to Python 3 and GNOME's move to introspection can make it way easier by making obsolete an awful lot of CPython code. This will also make possible in the future to use other Python implementations than CPython for coding GNOME applications.
As the week progressed introspection got more and more present in Ubuntu's plans, which makes me very happy. Follows some of the most relevant mentions of it, check the whiteboard section of each blueprint for the details:
How do we get to Python 3 and do we go through 2.7 first? "Port PyGI to python3. Move python2 applications to use PyGI." There's lots we can do upstream to help with this, from providing a script to convert to the new API to create a compatibility layer in PyGI. We'll be discussing the creation of a mailing list for coordinating PyGObject and PyGI development and helping with the porting from the static bindings.
How GObject Introspection will change our platform "Actions: Package PyGI for Ubuntu (Python 2) [robert-ancell], create or hijack a mailing list for pygi development"
Fun and Easy Python API for Telepathy We are adding API to telepathy-glib in this direction and nobody has shown interest in working on new static bindings for it, so we need PyGI in order to access the new API.
packagekit as backend for software-center "Python API is out-of-date. It would require some adaption, especially since 0.6.x will break API. Packagekit-glib2 was written with gobject introspection support. So bindings could be generated in the future."
Review coming changes in GNOME and what we will want to do "Python introspection bindings well progressed at sprint. No resource for GLib introspection work. Libraries will stop making bindings and rely on introspection - we have to migrate at some time to keep bindings"
And there seems to have been also interest in introspection from the people pushing for Midgard in Ubuntu.
In summary, I'm very happy to count on Ubuntu in the development of PyGI, I plan to report in this blog about the progresses in polishing PyGI and porting apps to the new API.
P.S.: I'm under the impression that Planet GNOME is not widely read by Ubuntu people, so if someone could rely it to their planet, would be awesome.
On the GNOME front, I tried to understand Ubuntu plans regarding introspection and developing with Python. At the beginning I was very concerned because the developers I talked to didn't seemed to be aware of the changes that introspection would bring to GNOME and thus hadn't any strategy in place.
The most notable effect of the appearance of introspection support in GNOME is that the existing static bindings for Python and other languages will stop being maintained and no new bindings will be developed for new APIs. For downstreams such as Ubuntu this means that they will either have to maintain and develop static bindings themselves alone, or move to use introspection. See here for an explanation of how apps in python would use introspection to call GObject C code.
If Ubuntu limited itself to package whatever software upstream releases, they could just sit waiting for new releases and update the dependencies accordingly. But turns out they produce a lot of Python code themselves and thus need to get involved in this transition for their own good. They also have the goal of being a great platform for developing desktop apps with Python, and introspection will play a major role in that.
Jorge Castro was tremendously helpful by presenting myself to Barry Warsaw, who has a responsibility role in Ubuntu's use of Python. Barry has been working on the transition to Python 3 and GNOME's move to introspection can make it way easier by making obsolete an awful lot of CPython code. This will also make possible in the future to use other Python implementations than CPython for coding GNOME applications.
As the week progressed introspection got more and more present in Ubuntu's plans, which makes me very happy. Follows some of the most relevant mentions of it, check the whiteboard section of each blueprint for the details:
How do we get to Python 3 and do we go through 2.7 first? "Port PyGI to python3. Move python2 applications to use PyGI." There's lots we can do upstream to help with this, from providing a script to convert to the new API to create a compatibility layer in PyGI. We'll be discussing the creation of a mailing list for coordinating PyGObject and PyGI development and helping with the porting from the static bindings.
How GObject Introspection will change our platform "Actions: Package PyGI for Ubuntu (Python 2) [robert-ancell], create or hijack
Fun and Easy Python API for Telepathy We are adding API to telepathy-glib in this direction and nobody has shown interest in working on new static bindings for it, so we need PyGI in order to access the new API.
packagekit as backend for software-center "Python API is out-of-date. It would require some adaption, especially since 0.6.x will break API. Packagekit-glib2 was written with gobject introspection support. So bindings could be generated in the future."
Review coming changes in GNOME and what we will want to do "Python introspection bindings well progressed at sprint. No resource for GLib introspection work. Libraries will stop making bindings and rely on introspection - we have to migrate at some time to keep bindings"
And there seems to have been also interest in introspection from the people pushing for Midgard in Ubuntu.
In summary, I'm very happy to count on Ubuntu in the development of PyGI, I plan to report in this blog about the progresses in polishing PyGI and porting apps to the new API.
P.S.: I'm under the impression that Planet GNOME is not widely read by Ubuntu people, so if someone could rely it to their planet, would be awesome.
Friday, May 7, 2010
Two talks in Greece about Sugar
The nice people at EELLAK have invited Simon and me to discuss the software side of their 1-to-1 deployments.
We'll be Saturday 15th in Athens and Sunday 16th in Thessaloniki, so if you happen to be there and are interested in discussing about Sugar, OLPC or free software in general, check out the program and appear.
Wednesday, May 5, 2010
Going to UDS-M
Canonical has been so nice to sponsor my attendance to the next Ubuntu Developer Summit in Brussels next week and Collabora is sponsoring my time there for Telepathy, Python and Sugar stuff. Thanks a lot to both companies.
The Ubuntu community has interest in making as easy as possible for regular users to create software and part of this effort is having a high-level API for having collaboration across the network. This of course will involve Telepathy and I have also a big interest in providing this experience to users of Sugar. Collabora are going to be flying as well some of their Telepathy developers to work on this and I look forward to finally meeting them.
Ubuntu has also committed heavily on Python for their development efforts, both on the desktop and in the server. For the desktop side of things, Python on GNOME is facing several challenges right now and I will be happy to help them make sure they don't lose any opportunities because of that. The challenges I have referred to are the obsolescence of static library bindings and the update to Python 3. On both issues Red Hat has contributed several developers to upstream and I will be happiest to discuss how we can also make Ubuntu contributors most welcome there. I'm also looking forward to finally meet Simon van der Linden in person after working together in PyGI for so long, he happens to live close to the venue so he'll jump to say hello and maybe do some hacking together (I have some patches in the queue that could use some review love).
There's also interest from Edubuntu in shipping Sugar, so I have registered to their blueprint and will be available to answer any questions they have regarding it. I have felt sad often when Ubuntu users have come asking how they could run Sugar on their machines and I had to point them to the instructions to build from the source, so it's great to have the possibility for Sugar to be accepted and supported by Ubuntu at last.
The Ubuntu community has interest in making as easy as possible for regular users to create software and part of this effort is having a high-level API for having collaboration across the network. This of course will involve Telepathy and I have also a big interest in providing this experience to users of Sugar. Collabora are going to be flying as well some of their Telepathy developers to work on this and I look forward to finally meeting them.
Ubuntu has also committed heavily on Python for their development efforts, both on the desktop and in the server. For the desktop side of things, Python on GNOME is facing several challenges right now and I will be happy to help them make sure they don't lose any opportunities because of that. The challenges I have referred to are the obsolescence of static library bindings and the update to Python 3. On both issues Red Hat has contributed several developers to upstream and I will be happiest to discuss how we can also make Ubuntu contributors most welcome there. I'm also looking forward to finally meet Simon van der Linden in person after working together in PyGI for so long, he happens to live close to the venue so he'll jump to say hello and maybe do some hacking together (I have some patches in the queue that could use some review love).
There's also interest from Edubuntu in shipping Sugar, so I have registered to their blueprint and will be available to answer any questions they have regarding it. I have felt sad often when Ubuntu users have come asking how they could run Sugar on their machines and I had to point them to the instructions to build from the source, so it's great to have the possibility for Sugar to be accepted and supported by Ubuntu at last.
Using telepathy-glib in python through gobject-introspection
Until now, you had two options for writing telepathy clients in python: use the low level D-Bus API through dbus-python, or using telepathy-python which provided very little more for clients apart from registering the zillion of constants in Telepathy.
Telepathy-glib is a library that provides a higher level API for interacting with the Telepathy framework than the low level D-Bus API. No languages bindings exist currently for this library so only C apps such as Empathy used it, developers using languages such as Python and JavaScript were stuck with the D-Bus API and generally each app invented a more or less complete new API on top of it.
In parallel to a push for adding more high-level APIs to telepathy-glib, we are looking at what remains to be done in the gobject-introspection stack so we don't need to write static bindings for each language. After some weeks hacking on Gjs (Danielle Madeley), Vala (Travis Reitter) and PyGI (me) things are starting to take shape.
Following Danni's post on her progress, here comes an example observer written in Python and using PyGI to call telepathy-glib:
This needs the latest code in telepathy-glib, gobject-introspection and pygi, and also a patch to PyGI that hasn't been release yet.
Telepathy-glib is a library that provides a higher level API for interacting with the Telepathy framework than the low level D-Bus API. No languages bindings exist currently for this library so only C apps such as Empathy used it, developers using languages such as Python and JavaScript were stuck with the D-Bus API and generally each app invented a more or less complete new API on top of it.
In parallel to a push for adding more high-level APIs to telepathy-glib, we are looking at what remains to be done in the gobject-introspection stack so we don't need to write static bindings for each language. After some weeks hacking on Gjs (Danielle Madeley), Vala (Travis Reitter) and PyGI (me) things are starting to take shape.
Following Danni's post on her progress, here comes an example observer written in Python and using PyGI to call telepathy-glib:
import gobject
gobject.threads_init()
from gi.repository import TelepathyGLib
#TelepathyGLib.debug_set_flags('all')
def observe_channels(observer, account, connection, channels,
dispatch_op, requests, context, user_data):
print 'observe_channels'
print 'account = %s' % account.get_object_path()
print 'connection = %s' % connection.get_object_path()
for channel in channels:
print 'channel = %s' % channel.get_object_path()
if dispatch_op is not None:
print 'dispatch_op = %s' % dispatch_op.get_object_path()
else:
print 'dispatch_op = None'
if requests is not None:
for request in requests:
print 'request = %s' % request.get_object_path()
context.accept()
dbus = TelepathyGLib.DBusDaemon.dup()
observer = TelepathyGLib.SimpleObserver.new(dbus, True, 'PythonObserver', True,
observe_channels, None)
observer.add_observer_filter({
TelepathyGLib.PROP_CHANNEL_CHANNEL_TYPE: TelepathyGLib.IFACE_CHANNEL_TYPE_TEXT,
})
observer.register()
main_loop = gobject.MainLoop()
main_loop.run()
This needs the latest code in telepathy-glib, gobject-introspection and pygi, and also a patch to PyGI that hasn't been release yet.
Monday, April 19, 2010
The 2010 Python GNOME hackfest is done!
Everything has to come to an end, and though this week has been full of hacking fun and beer work, I will welcome some rest back at home. Follows a recount of the time here.
After arriving to Boston last Monday, dropped my stuff in J5's house and went together to have some beers with some Sugar SLOB's at the CBC, there I finally met Colin Walters, putting one more face to an IRC nick. Afterwards we went to the OLPC offices to discuss Sugar Labs' trademark policy, and though I had to leave shortly after because of the lack of sleep, turns out they swiftly solved this issue that has been dragging on for so long, congrats!
On Tuesday several of the Sugar SLOB's got together to discuss miscellanous stuff about Sugar, mainly doing some high-bandwidth chatter to share our positions on several issues. Discussions should follow soon on the IAEP mailing list.
Wednesday started the hackfest, met Zach Goldberg, John Ehresman (of Wingware fame) and Red Hat's David Malcolm. I'm still impressed by the professionalism and technical knowledge of these guys, it allowed us to keep a strong focus and to overcome together the roadblocks we found, even when we weren't able to agree on a single position. David partnered with John and J5 on the Python 3.x side, and Colin, Zach and me on the introspection side. Having in the same room people with as a deep knowledge of Python such as John and David also helped a lot to the introspection side of things.
From Thursday to Sunday we just continued hacking on our goals, from 9am to 6pm on the OLPC offices with a small pause to grab food. Was so much fun that we only stopped when our brains grinded to a halt. Check the links below from Zach for more details about each day.
On Saturday night we celebrated the first PyGI release: 0.5. One very important outcome of the hackfest is that Zach has joined the maintenance team of PyGI, assuring its continuity, this will mean that PyGI will have a well triaged list of bugs, patches will be reviewed on time and releases will be made on time. Simon van der Linden (who unfortunately couldn't make it to Boston) and me will be lending a hand on that from time to time.
The Python 3.x patches haven't landed yet because are very invasive and we need to make sure we don't introduce more regressions than what can be fixed timely, we don't want to break all PyGTK software out there! So the plan is to keep developing the Py3k ports of PyGObject and PyGI in separate branches and test them with big codebases such as Sugar until we are confident of their stability, then we'll propose the merge. Both ports are feature complete and ready to be tested, which is a giant step forward.
I'm very grateful to my employer Collabora for having sponsored the time I spent hacking on PyGObject (and traveling!), to the GNOME Foundation for sponsoring my trip, to my OLPC colleagues for lending us their facilities, to Red Hat for taking us out for dinner and to Canonical for the coffee. Also, my special admiration to Red Hat for understanding that a strong downstream requires a strong upstream and sending three of its best hackers to lend us a hand here.
You can read more about the hackfest from others:
* http://arstechnica.com/open-source/reviews/2010/04/python-support-in-gnome-gets-a-boost-from-hackfest.ars
* http://blog.verbum.org/2010/04/14/pygtk-performing-engine-maintenance-while-the-car-is-running/
* http://zachgoldberg.com/2010/04/15/gnomepython-hackfest-2010-day-2-or-how-to-actually-coordinate-packages/
* http://zachgoldberg.com/2010/04/17/pygi-hackfest-day-4-a-call-back-to-the-past/
* http://zachgoldberg.com/2010/04/18/pygi-version-0-5-the-watch-out-theres-a-volcano-release/
* http://www.j5live.com/2010/04/12/gnome-python-hackfest-thanks-to-sponsors/
* http://www.j5live.com/2010/04/14/caffeined-up-and-starting-to-hack/
* http://www.j5live.com/2010/04/14/gnome-python-hackfest-day-1/
* http://www.j5live.com/2010/04/15/gnome-python-hackfest-day-2-quick-roundup/
After arriving to Boston last Monday, dropped my stuff in J5's house and went together to have some beers with some Sugar SLOB's at the CBC, there I finally met Colin Walters, putting one more face to an IRC nick. Afterwards we went to the OLPC offices to discuss Sugar Labs' trademark policy, and though I had to leave shortly after because of the lack of sleep, turns out they swiftly solved this issue that has been dragging on for so long, congrats!
On Tuesday several of the Sugar SLOB's got together to discuss miscellanous stuff about Sugar, mainly doing some high-bandwidth chatter to share our positions on several issues. Discussions should follow soon on the IAEP mailing list.
Wednesday started the hackfest, met Zach Goldberg, John Ehresman (of Wingware fame) and Red Hat's David Malcolm. I'm still impressed by the professionalism and technical knowledge of these guys, it allowed us to keep a strong focus and to overcome together the roadblocks we found, even when we weren't able to agree on a single position. David partnered with John and J5 on the Python 3.x side, and Colin, Zach and me on the introspection side. Having in the same room people with as a deep knowledge of Python such as John and David also helped a lot to the introspection side of things.
From Thursday to Sunday we just continued hacking on our goals, from 9am to 6pm on the OLPC offices with a small pause to grab food. Was so much fun that we only stopped when our brains grinded to a halt. Check the links below from Zach for more details about each day.
On Saturday night we celebrated the first PyGI release: 0.5. One very important outcome of the hackfest is that Zach has joined the maintenance team of PyGI, assuring its continuity, this will mean that PyGI will have a well triaged list of bugs, patches will be reviewed on time and releases will be made on time. Simon van der Linden (who unfortunately couldn't make it to Boston) and me will be lending a hand on that from time to time.
The Python 3.x patches haven't landed yet because are very invasive and we need to make sure we don't introduce more regressions than what can be fixed timely, we don't want to break all PyGTK software out there! So the plan is to keep developing the Py3k ports of PyGObject and PyGI in separate branches and test them with big codebases such as Sugar until we are confident of their stability, then we'll propose the merge. Both ports are feature complete and ready to be tested, which is a giant step forward.
I'm very grateful to my employer Collabora for having sponsored the time I spent hacking on PyGObject (and traveling!), to the GNOME Foundation for sponsoring my trip, to my OLPC colleagues for lending us their facilities, to Red Hat for taking us out for dinner and to Canonical for the coffee. Also, my special admiration to Red Hat for understanding that a strong downstream requires a strong upstream and sending three of its best hackers to lend us a hand here.
You can read more about the hackfest from others:
* http://arstechnica.com/open-source/reviews/2010/04/python-support-in-gnome-gets-a-boost-from-hackfest.ars
* http://blog.verbum.org/2010/04/14/pygtk-performing-engine-maintenance-while-the-car-is-running/
* http://zachgoldberg.com/2010/04/15/gnomepython-hackfest-2010-day-2-or-how-to-actually-coordinate-packages/
* http://zachgoldberg.com/2010/04/17/pygi-hackfest-day-4-a-call-back-to-the-past/
* http://zachgoldberg.com/2010/04/18/pygi-version-0-5-the-watch-out-theres-a-volcano-release/
* http://www.j5live.com/2010/04/12/gnome-python-hackfest-thanks-to-sponsors/
* http://www.j5live.com/2010/04/14/caffeined-up-and-starting-to-hack/
* http://www.j5live.com/2010/04/14/gnome-python-hackfest-day-1/
* http://www.j5live.com/2010/04/15/gnome-python-hackfest-day-2-quick-roundup/
Wednesday, April 7, 2010
Python + GNOME hackfest is set
Everything is ready for the hackfest that will update Python as a great language with which to program in GNOME.
In case you want to hack with us but cannot be at Cambridge, the attendants are going to hang on the#pygobject #pygtk, #pygi and #introspection channels at GIMPNet. Just say hi and we'll find something cool on which to hack together.
Update: channel #pygobject doesn't exist, should have written #pygtk instead.
In case you want to hack with us but cannot be at Cambridge, the attendants are going to hang on the
Update: channel #pygobject doesn't exist, should have written #pygtk instead.
Friday, March 19, 2010
Sugar with better Telepathy
After three weeks of little coding but much reading, a reward:
This shows the Chat activity talking to Empathy through link-local xmpp. This was already possible, but the difference now is that Chat is a normal telepathy client, and it has been activated by dbus as would be any other telepathy-enable application in GNOME, Meego or whatever.
The current code is very sketchy, but we are starting to get a good sense of the next challenges. If you are interested in knowing why this is important, see my previous post.
Progress can be followed in this page.
This shows the Chat activity talking to Empathy through link-local xmpp. This was already possible, but the difference now is that Chat is a normal telepathy client, and it has been activated by dbus as would be any other telepathy-enable application in GNOME, Meego or whatever.
The current code is very sketchy, but we are starting to get a good sense of the next challenges. If you are interested in knowing why this is important, see my previous post.
Progress can be followed in this page.
Saturday, March 6, 2010
Update on the Python/GNOME hackfest
The hackfest is going to happen from 14th to 18th April in Boston (MA, USA). We haven't agreed yet on a venue, but we are aiming for something near Kendall Square.
We'll be 3 people working on Python 3 support, and 3 more on the introspection bindings. More details at http://live.gnome.org/Hackfests/Python2010.
The GNOME Foundation will be sponsoring the travel, an as-of-yet unnamed sponsor will be providing the venue and the GNOME Foundation board is busy looking for sponsors for hacking food and such.
We'll be 3 people working on Python 3 support, and 3 more on the introspection bindings. More details at http://live.gnome.org/Hackfests/Python2010.
The GNOME Foundation will be sponsoring the travel, an as-of-yet unnamed sponsor will be providing the venue and the GNOME Foundation board is busy looking for sponsors for hacking food and such.
Wednesday, March 3, 2010
Early childhood hackers
Of course, Sugar hasn't the monopoly in FOSS in primary classrooms, but are there other projects whose contributors include those children? Teacher L.M.Y.Lim is working to make that happen:
And Mel briefed about their first meeting with the community.
...
- I have to narrow my focus on the goals I have for the children. Objectives will include:
The children will generate a list of responsibilities a QA engineer, or “tester” has;
The children will generate a list of what makes a good QA engineer;
The children will write about their experience – not only about what they figured things out, but also how they did it.
The children will provide feedback for future SoaS deployment or pilots.
...
And Mel briefed about their first meeting with the community.
Tuesday, March 2, 2010
My focus during 0.90: Collaboration
From now on to the next Sugar release in about 6 months (0.90), I'm going to be working on improving the collaboration stack in Sugar, graciously sponsored by Collabora. Collabora employees developed almost all of the collaboration code in Sugar, and are the main force behind the Telepathy framework, on which Sugar's collaboration is based. Though pervasive collaboration is one of the major features of Sugar, it hasn't been funded for a long time and there's large room for improvement, also due to the new developments in Telepathy. My work will aim to make presence and collaboration more reliable and to put the pieces in place for enriching the experience with the new features in Telepathy.
Collabora has almost 5 years of experience in open source software so they know very well that for a project to survive, someone needs to take the role of software maintenance, and that's why they are going to be sponsoring me as well 1-2 days per week of maintenance work. Maintenance work includes tasks such as reviewing proposed changes, maintaining the bug database, participating in community discussions, welcoming new contributors, making new releases, etc, and is fundamental in keeping an open source project such as Sugar alive. That's why I would like to put a call for our many users of Sugar to help the other maintainers keep doing their work by supporting them financially. As of today the only Sugar maintainers that are paid anything for doing their job are Sayamindu and me, and this is not sustainable.
The grunt of the work will be dropping custom code that was developed ad-hoc in the early days and making Sugar use instead new developments in Telepathy. Many of the bugs we see today in collaboration are due to the several layers on which collaboration information is cached. By dropping the Presence Service and having activities call Telepathy directly, we'll improve the reliability of presence and collaboration.
There's also code in Telepathy that is exclusively for Sugar and that is redundant now due to new developments in other parts of Telepathy. I will be working as well in making Sugar don't need those specific mechanisms because the Telepathy maintainers will drop those pieces at some point and Sugar cannot be left behind. As well, Sugar depends on the server being configured in an specific way, breaking collaboration with non-Sugar specific servers, there will be work as well to remove this limitation.
By using the same pieces as other environments such as GNOME and MeeGo, Sugar will be closer to the development of those platforms and will be in a better position to take advantage from new features. We'll be reducing as well the effort required to maintain and further develop our collaboration stack, and we'll be sharing with others the burden of keeping our collaboration foundations solid.
Many of the changes will be under the hood and won't be seen nor by users nor by activity developers. Other changes will affect developers because API that they were using won't be there any more, I'm going of course to try to minimize this as much as possible. Other changes will impact the UI, mostly by adding new features, but sometimes will be changes required to make Sugar closer to the other Telepathy clients. I will be starting discussions very soon about all these changes so we can find the best solutions for each.
In summary, Sugar will improve in these ways:
- the collaboration code will be smaller and simpler,
- Sugar users will be able to collaborate through more networks, with more protocols, and with people not using Sugar,
- Sugar will be more compatible with future versions of Telepathy,
- we'll have a simpler path to acquire recent and upcoming features in Telepathy and related frameworks, such as VOIP and video calls.
Collabora has almost 5 years of experience in open source software so they know very well that for a project to survive, someone needs to take the role of software maintenance, and that's why they are going to be sponsoring me as well 1-2 days per week of maintenance work. Maintenance work includes tasks such as reviewing proposed changes, maintaining the bug database, participating in community discussions, welcoming new contributors, making new releases, etc, and is fundamental in keeping an open source project such as Sugar alive. That's why I would like to put a call for our many users of Sugar to help the other maintainers keep doing their work by supporting them financially. As of today the only Sugar maintainers that are paid anything for doing their job are Sayamindu and me, and this is not sustainable.
The grunt of the work will be dropping custom code that was developed ad-hoc in the early days and making Sugar use instead new developments in Telepathy. Many of the bugs we see today in collaboration are due to the several layers on which collaboration information is cached. By dropping the Presence Service and having activities call Telepathy directly, we'll improve the reliability of presence and collaboration.
There's also code in Telepathy that is exclusively for Sugar and that is redundant now due to new developments in other parts of Telepathy. I will be working as well in making Sugar don't need those specific mechanisms because the Telepathy maintainers will drop those pieces at some point and Sugar cannot be left behind. As well, Sugar depends on the server being configured in an specific way, breaking collaboration with non-Sugar specific servers, there will be work as well to remove this limitation.
By using the same pieces as other environments such as GNOME and MeeGo, Sugar will be closer to the development of those platforms and will be in a better position to take advantage from new features. We'll be reducing as well the effort required to maintain and further develop our collaboration stack, and we'll be sharing with others the burden of keeping our collaboration foundations solid.
Many of the changes will be under the hood and won't be seen nor by users nor by activity developers. Other changes will affect developers because API that they were using won't be there any more, I'm going of course to try to minimize this as much as possible. Other changes will impact the UI, mostly by adding new features, but sometimes will be changes required to make Sugar closer to the other Telepathy clients. I will be starting discussions very soon about all these changes so we can find the best solutions for each.
In summary, Sugar will improve in these ways:
- the collaboration code will be smaller and simpler,
- Sugar users will be able to collaborate through more networks, with more protocols, and with people not using Sugar,
- Sugar will be more compatible with future versions of Telepathy,
- we'll have a simpler path to acquire recent and upcoming features in Telepathy and related frameworks, such as VOIP and video calls.
Friday, February 26, 2010
Make Your Own Sugar Activities!
James Simmons has been working for the last months in a manual about writing activities for the Sugar platform, you can get it from the FLOSS Manuals site along other Sugar and FLOSS documentation.
If you had wanted to contribute to the pool of educational activities for Sugar and found it hard to get all the details right, it should be now much easier for you to help more children around the world to get better learning.
If you had wanted to contribute to the pool of educational activities for Sugar and found it hard to get all the details right, it should be now much easier for you to help more children around the world to get better learning.
Wednesday, February 24, 2010
Visit to Igalia
New Igalia office by
Berto Garcia under CC BY-SA 2.0
The morning of the first day was spent with Juan José Sánchez, who explained to me the ways in which they are a special company. Igalia's management structure is very flat, with responsibility fairly distributed among its partners, which are 70% of its employees. This means among other things that when the company participates in a project, the people working on it are going to be more committed than if they just were assigned by their managers.
The first talk started that day after lunch, intended to give an overview of Sugar's origins, its present state and perspectives of future. The goal was two-fold: give them enough background so they could more efficiently jump into the community, and present a case of a FOSS project to the Master on Free Software students. The best of the session was without doubt their questions and the discussions that ensued afterwards, I'm happy I was able to pick their interest! The slides (in Spanish) can be found here.
After a break, we held a workshop about hacking on Sugar. The audience had a varied technical background, including experienced GNOME developers but also students of the Master on Free Software with little or no knowledge of GNOME hacking, so I tried to jump over the details that are not specific to Sugar and to highlight the specifics of contributing code to Sugar, in the hope that our online resources will be able to fill the gaps. I started introducing them to our jhbuild instance, went quickly through the core modules in git, explained the code review process and went through the process of contributing a trivial bugfix. Then moved to activities, explaining the layout of a simple Python activity and then the couple of X window properties that need to be set so the Sugar shell can recognize a top level window as belonging to an activity. We also spent some time peeking inside a few Sugar activities such as Browse and Write.
Morning next day, several Igalians approached me to talk about the different ways in which Sugar could benefit from their work:
Sergio Villar showed me the work that has gone recently into Tinymail (a library that provides an email backend) clients using different toolkits. They have been refactoring Modest so more code can be shared between the Hildon and Gtk+ based versions, paving the way for more Tinymail-based experiences. Though we haven't heard calls often for an email client in Sugar, this may be due to the fact that we hear most about Sugar deployments that are well connected to Internet, thus being able to use an on-line email service. This makes me think that there may be indeed a need for an email client that allows an async experience, for places with intermittent connectivity such as remote Peru where often not even electricity is available. Sergio has been quick to test his ideas and has blogged about it already.
Alejandro Piñeiro talked to me about his work on the accessibility layers in the GNOME stack. He has been working recently on the accessibility bits in Clutter and Hildon, so already has a very good idea of the work needed in the Sugar shell and toolkit so screen readers such as Orca can do their job. This will play a very important part in Sugar's accessibility story, on which I hope to write soon in more detail here.
Iago Toral has worked in the multimedia infrastructure for Maemo and has recently been involved in Grilo, a framework for media acquisition and reproduction. He envisioned an activity that would provide a rich UI for searching, browsing and reproducing educational media. These UIs already exist in the form of web apps, but an activity could have benefits such as more responsive and focused UIs, automatic caching, using secondary sources depending on connectivity, etc. We still need to understand better how Grilo could grow support for users contributing media to online services.
Mario Sánchez and Juan José Sánchez took some time to discuss how WebKit/GTK+ could be put to use in the Sugar platform (though we already use it in Read for rendering EPUB books). We discussed the feasibility of adapting Epiphany to run as an activity, and also port the Browse activity to use Webkit instead of Mozilla. This can be very important for Sugar, because distros such as Ubuntu are talking about dropping support for embedders of Mozilla, and because WebKit/GTK+'s accessibility is improving very quickly because of Igalia's work.
As you can see, this has been an incredibly productive trip, bringing on the table several opportunities for growing Sugar on top of new GNOME technologies, on which Igalia has an impressive knowledge. I'm also very happy to see the interest that Sugar has raised on our colleagues from Igalia, and I'm very confident on their capability to make excellent contributions to Sugar if they chose to.
Monday, February 15, 2010
Free love
A fan of free software sent this greeting yesterday to me, addressed to the Sugar community and to other free software projects:
free software foundation suggests people send valentine's greetings to free software developers. i could be wrong, but i think it's a great idea. i don't get many excuses to bother devs with thank yous.
i'm not only a huge fan of sugar. i have sugar to thank for helping introduce me to all of these: linux-libre (via trisquel-con-sugar) trisquel, python, gnewsense. i tried trisquel because it included sugar, i learned python because of pippy. after 25 years of coding in basic, python is probably my favorite language.
i know sugar is developed for kids and that's great. i learned basic as a kid, and i believe very strongly in pippy and i think turtleart is absolutely ingenious.
i know i have (a) team(s) to thank, but in the interest of not making spam filters angry and retributive i'm just sending this valentine to you. maybe you'll share it? thanks everyone.
Friday, February 5, 2010
Hackfest on Python 3 and GObject introspection
J5 has had the great idea of proposing a GNOME Foundation-sponsored hackfest to bring needed pushes to Python 3 and GObject Introspection support to PyGObject.
The situation in which we are today is not very comfortable, as more and more people are wanting to move their projects to Python 3.x and the old static bindings are not being able to cope with new API added to existing libraries and with new GObject-based libraries. A lot of people out there are known to be using PyGTK in long-term projects, so we really need to get our act together.
AFAICS, the plan on the table right now is to make PyGObject and PyGI run on Python 3.x and drop the static bindings, instead of having to port all of them to Python 3.x. Another possibility is to drop PyGObject altogether and have standalone python bindings for GObject Introspection, but that would reimplement lots of stuff already in PyGObject.
Have started a thread in the PyGTK mailing list: http://www.daa.com.au/pipermail/pygtk/2010-February/018222.html
Please pass this idea to whoever you think could be interested, more details will come soon.
UPDATE: have started a proposal in the GNOME wiki: http://live.gnome.org/Hackfests/Python2010. Once we have a better idea of who is interested in attending, I will complete it further.
The situation in which we are today is not very comfortable, as more and more people are wanting to move their projects to Python 3.x and the old static bindings are not being able to cope with new API added to existing libraries and with new GObject-based libraries. A lot of people out there are known to be using PyGTK in long-term projects, so we really need to get our act together.
AFAICS, the plan on the table right now is to make PyGObject and PyGI run on Python 3.x and drop the static bindings, instead of having to port all of them to Python 3.x. Another possibility is to drop PyGObject altogether and have standalone python bindings for GObject Introspection, but that would reimplement lots of stuff already in PyGObject.
Have started a thread in the PyGTK mailing list: http://www.daa.com.au/pipermail/pygtk/2010-February/018222.html
Please pass this idea to whoever you think could be interested, more details will come soon.
UPDATE: have started a proposal in the GNOME wiki: http://live.gnome.org/Hackfests/Python2010. Once we have a better idea of who is interested in attending, I will complete it further.
60.000 children more will learn with Sugar in Argentina
Thanks to OLPC and their local government, every child in the Argentinian state of La Rioja will use Sugar to learn, both at school and outside. Note that this includes thousands of children (and families) that would have never owned a computer otherwise.
I'm happy to note that they see the Uruguayan experience as a model to follow. In Uruguay the laptop deployment is something that the whole society has taken ownership of and thus is having a deep and broad impact everywhere.
I'm looking forward to work with the Argentinian free software community in improving the educational opportunities of their children through hacking on Sugar.
Thanks to Gonzalo Odiard from Sugar Labs Argentina for passing the news.
I'm happy to note that they see the Uruguayan experience as a model to follow. In Uruguay the laptop deployment is something that the whole society has taken ownership of and thus is having a deep and broad impact everywhere.
I'm looking forward to work with the Argentinian free software community in improving the educational opportunities of their children through hacking on Sugar.
Thanks to Gonzalo Odiard from Sugar Labs Argentina for passing the news.
Two Sugar talks in A Coruña
Next week I'll be giving two talks about Sugar in the Igalia office in A Coruña, Galiza, Spain. The first one will be of introductory nature, talking about Sugar's history, the community around it and future perspectives. The second will be more of a workshop on how to contribute features and bug fixes. The talks will be part of the Free Software Master that Igalia runs in partnership with the Rey Juan Carlos University, but other interested people are welcome to join us.
The talks will be in Spanish and will take place on Thursday 11th February 2010 from 16 to 19, at Bugallal Marchesi, 22, 1º, A Coruña:
* 16:00-17:15 Introducción a Sugar, historia, comunidad, oportunidades
* 17:45-19:00 Charla técnica / taller sobre cómo realizar contribuciones
I'm very happy to see Igalia's interest on Sugar, in my opinion it isn't a coincidence that a company with a strong commitment to Free Software sees education as an important area through which fulfil their social mission.
The talks will be in Spanish and will take place on Thursday 11th February 2010 from 16 to 19, at Bugallal Marchesi, 22, 1º, A Coruña:
* 16:00-17:15 Introducción a Sugar, historia, comunidad, oportunidades
* 17:45-19:00 Charla técnica / taller sobre cómo realizar contribuciones
I'm very happy to see Igalia's interest on Sugar, in my opinion it isn't a coincidence that a company with a strong commitment to Free Software sees education as an important area through which fulfil their social mission.
Saturday, January 30, 2010
One more opportunistic dot
As member of the Sugar community, I'm very happy to read from Jono Bacon the Ubuntu plans about what he calls opportunistic programmers. In Sugar we believe that doing is an important part of learning, that's one of the reasons for considering free software a fundamental part of what we do.
Though the goals stated in the referred post match almost exactly what we are aiming for as well, I find something missing: bigger components to create your applications with. Python, the GNOME platform and DesktopCouch are awesome technologies that fit very well for this purpose (Sugar itself is built on Python and GNOME) but the components provided are rather small, meaning that you need to build all the functionality you need from these small bricks. What if you want to generate a PDF and want a real-time preview? Or an ODT document? One that users edit collaboratively across the network in real time? Would you have to write those thousands of lines yourself?
We have thought that by also providing coarse components such as Abiword, Evince, Mozilla and Gnash that people can use in their applications, what user-programmers can do widens considerably, keeping the complexity of their own code to a minimum.
I know this will sound to some as too much like Bonobo, but really, this is so much more light-weight both in computational and human resources terms, and most importantly, it's being widely used today. My post about embedding evince is the most popular in this blog, one year after it was written.
I would like to see a bigger effort from GNOME application developers so their code can be reused in this way. It helps to all those people building new user experiences based on GNOME (no more #ifdef HILDON!) and also can lower the pressure that users with marginal or specially complex needs put sometimes on GNOME developers.
Though the goals stated in the referred post match almost exactly what we are aiming for as well, I find something missing: bigger components to create your applications with. Python, the GNOME platform and DesktopCouch are awesome technologies that fit very well for this purpose (Sugar itself is built on Python and GNOME) but the components provided are rather small, meaning that you need to build all the functionality you need from these small bricks. What if you want to generate a PDF and want a real-time preview? Or an ODT document? One that users edit collaboratively across the network in real time? Would you have to write those thousands of lines yourself?
We have thought that by also providing coarse components such as Abiword, Evince, Mozilla and Gnash that people can use in their applications, what user-programmers can do widens considerably, keeping the complexity of their own code to a minimum.
I know this will sound to some as too much like Bonobo, but really, this is so much more light-weight both in computational and human resources terms, and most importantly, it's being widely used today. My post about embedding evince is the most popular in this blog, one year after it was written.
I would like to see a bigger effort from GNOME application developers so their code can be reused in this way. It helps to all those people building new user experiences based on GNOME (no more #ifdef HILDON!) and also can lower the pressure that users with marginal or specially complex needs put sometimes on GNOME developers.
Monday, January 25, 2010
Moving on to other things
If you have been following my blog, you may have noticed that I see Sugar Labs as having done a lot of progress recently in the sustainability front. This has been thanks to the efforts of several individuals, who gathered around Sugar Labs in the believe that computers could radically improve the educational opportunities of children anywhere in the world, and that none of the pre-existing software environments was the best suited for the task.
It has been an awesome adventure, maybe the biggest in my life, but time has come for me to move to less thrilling matters. This doesn't mean that I'm cutting completely with Sugar, just that it will take now just a small part of my free time. I intend to skim through a couple of mailing lists, to organize bi-weekly meetings for the development team, and to review patches in the queue of my modules as time permits. I'm aiming to dedicate to all this only 5 hours per week to Sugar matters, so I will have to be very strict on where this time is spent.
I'm starting just now to look for my next job, so if you know of a position for someone knowledgeable of the GNOME platform, Python, with a good sense of FOSS communities and a taste for diving into big codebases, please do forward to me at tomeu@tomeuvizoso.net. Here is my resume.
It has been an awesome adventure, maybe the biggest in my life, but time has come for me to move to less thrilling matters. This doesn't mean that I'm cutting completely with Sugar, just that it will take now just a small part of my free time. I intend to skim through a couple of mailing lists, to organize bi-weekly meetings for the development team, and to review patches in the queue of my modules as time permits. I'm aiming to dedicate to all this only 5 hours per week to Sugar matters, so I will have to be very strict on where this time is spent.
I'm starting just now to look for my next job, so if you know of a position for someone knowledgeable of the GNOME platform, Python, with a good sense of FOSS communities and a taste for diving into big codebases, please do forward to me at tomeu@tomeuvizoso.net. Here is my resume.
The Karma Project: Code Less, Teach More
My last post listed some of the organizations that are putting some of their resources to work on Sugar with us. Though that list is complete to the best of my knowledge, there's another partner of Sugar Labs that is doing a great effort to work with others in improving educational opportunities around the world: OLE Nepal.
OLE Nepal is running a deployment of 4400 OLPC XOs and are working on content creation and teacher training along with laptop distribution and maintenance. They started by using Squeak Etoys as the platform for their materials, then switched to Flash because they couldn't find enough people with Squeak skills, and finally have launched the Karma project, which is based on HTML5 technologies.
They have released the 0.2 version and are now starting to port their existing content to Karma, some which you can see (and play!) here: http://karma.sugarlabs.org/.
I think this project is extremely relevant for the reasons that Bryan Berry outlines in Karma: The Code Less, Teach More Software Framework:
I don't know of any other effort that can compare to Karma in educational content authoring, so it strikes me as very bold and far-sighted that educational NGOs in developing countries are taking FOSS components and are assembling them to create frameworks that the Adobes and Microsofts of the world have failed to create. So kudos to OLE Nepal and all the volunteers involved!
OLE Nepal is running a deployment of 4400 OLPC XOs and are working on content creation and teacher training along with laptop distribution and maintenance. They started by using Squeak Etoys as the platform for their materials, then switched to Flash because they couldn't find enough people with Squeak skills, and finally have launched the Karma project, which is based on HTML5 technologies.
They have released the 0.2 version and are now starting to port their existing content to Karma, some which you can see (and play!) here: http://karma.sugarlabs.org/.
I think this project is extremely relevant for the reasons that Bryan Berry outlines in Karma: The Code Less, Teach More Software Framework:
I have written a number of articles in olpcnews.com about the need for an activity framework built on openweb technologies (JavaScript, HTML). Here is the argument in three sentences. A large proportion of software developers are familiar with these technologies. This proportion is even larger in developing countries. The larger software industry is steadily embracing openweb technologies for web, mobile, and desktop development. Please note that Karma lessons can run both online and offline.
I don't know of any other effort that can compare to Karma in educational content authoring, so it strikes me as very bold and far-sighted that educational NGOs in developing countries are taking FOSS components and are assembling them to create frameworks that the Adobes and Microsofts of the world have failed to create. So kudos to OLE Nepal and all the volunteers involved!
Friday, January 22, 2010
Sugar Labs has changed
Less than 10 months ago I wrote a post about how Sugar Labs had managed to attract top professionals to contribute their leisure time, effort and talent to our mission of improving the educational opportunities of children all around the world.
Today I'm happy to look back and see how what was a 100% volunteer-run organization has welcomed other organizations to pool their resources to keep improving Sugar. In most cases these efforts have went on quite discreetly, even if they amount to a significant share of our new developments.
The organizations that are putting their employees to work on upstream Sugar are:
OLPC has put 3 of their engineers to work on Sugar through 2009, they have sold more than 1.5 million of machines with Sugar on them, so they have some interest.
* Daniel Drake (dsd) has taken maintenance of the 0.84 stable branch, has sent several patches for fixes and has contributed one major feature: OLPC mesh support.
* Sayamindu Dasgupta (unmadindu) has kept working on everything localization, improving the book reading capabilities of Sugar and is currently working on improving font size selection in Sugar. He is also maintainer of the 0.84 stable branch along with Daniel.
* Martin Langhoff has kept working on the integration of OLPC's school server with Sugar and has also been doing great work fixing regressions in Sugar's journal and handling of usb sticks.
Paraguay Educa is a NGO that is implementing an OLPC deployment in Caacupé, Paraguay. They have distributed 4000 XOs and though being a very small organization, they have surpassed any other OLPC deployer in working with the upstream communities of the software they use.
* Raúl Gutiérrez Segalés (rgs) has been working with Walter Bender on TurtleArt, a software that introduces young learners into algorithms and computation. He is also leading the technical team and has encouraged his colleagues to be bold and join the FOSS community.
* Martin Abente (tch) has been working on adding to Sugar the capability of using 3G modems. Aside from his involvement in Sugar, he is the main author of a logistics system specially developed for the task of deploying 1-to-1 programs. This system has been made FOSS by Paraguay Educa and is being offered to other OLPC deployments.
* César D. Rodas (crodas) is not working on Sugar (yet!), but he has been assigned to make Fedora 11 run well on the XO-1 machines. This is very important for Sugar Labs, because until there isn't a new release for the XO-1, +1.5 million machines will be stuck with very old software: Sugar 0.82 and Fedora 9. This is also important because deployments start to feel empowered to take on tasks that were seen previously as too hard to be taken by anybody outside the OLPC headquarters.
The Ceibal Plan is the name of the government project that has universalized computer access in primary education, Uruguay is the first country in the world to have achieved this and I'm happy that Sugar is the chosen software for each of the 366.000 machines. They have been modifying Sugar downstream to better adapt it to their needs, and have realized that by not upstreaming their work, it will be more expensive for them to update to new versions.
* Daniel Castelo (Daniel_C) has been put in charge of upstreaming their 3G modifications on top of the work that Martin Abente is doing. He is also working on adding printer support and has been thinking of implementing ADSL connections.
* Esteban Arias (esteban) has made excellent work adding accessibility features to Sugar and is now submitting them upstream. He's starting small for our next release (0.88) but he has lots more of very interesting stuff to upstream.
Though I find these developments very reassuring, I'm still quite a bit worried about the rest of the iceberg. If an organization deploying only 4000 machines is able to work internationally to develop the software to their local needs, which opportunities are losing the deployers of the million of machines that don't dare to participate in the development process?
There's also the issue of module maintenance: all Sugar modules are currently maintained by volunteers. When OLPC took maintenance of the 0.84 branch, they actually took work out from the shoulders of those volunteers, but the rest of the contributors are actually increasing the work that maintainers have to do because of feature discussion, code reviewing, bug triaging and stabilization. If the three volunteers that are maintaining most of Sugar run out of money and need to find a normal job, who is going to do that work?
Aside from module maintenance, there's also the roles of Feature Manager, Development team coordinator, Product Manager, System Administrator, etc. that need to be carried by someone. Deployments are going to need to participate in these other areas if they want to keep having a healthy place where to work together and pool their resources.
All in all, given what 2009 brought us, I'm thrilled when I try to imagine what 2010 has in for Sugar. Have a happy hacking year!
Today I'm happy to look back and see how what was a 100% volunteer-run organization has welcomed other organizations to pool their resources to keep improving Sugar. In most cases these efforts have went on quite discreetly, even if they amount to a significant share of our new developments.
The organizations that are putting their employees to work on upstream Sugar are:
One Laptop per Child
OLPC has put 3 of their engineers to work on Sugar through 2009, they have sold more than 1.5 million of machines with Sugar on them, so they have some interest.
* Daniel Drake (dsd) has taken maintenance of the 0.84 stable branch, has sent several patches for fixes and has contributed one major feature: OLPC mesh support.
* Sayamindu Dasgupta (unmadindu) has kept working on everything localization, improving the book reading capabilities of Sugar and is currently working on improving font size selection in Sugar. He is also maintainer of the 0.84 stable branch along with Daniel.
* Martin Langhoff has kept working on the integration of OLPC's school server with Sugar and has also been doing great work fixing regressions in Sugar's journal and handling of usb sticks.
Paraguay Educa
Paraguay Educa is a NGO that is implementing an OLPC deployment in Caacupé, Paraguay. They have distributed 4000 XOs and though being a very small organization, they have surpassed any other OLPC deployer in working with the upstream communities of the software they use.
* Raúl Gutiérrez Segalés (rgs) has been working with Walter Bender on TurtleArt, a software that introduces young learners into algorithms and computation. He is also leading the technical team and has encouraged his colleagues to be bold and join the FOSS community.
* Martin Abente (tch) has been working on adding to Sugar the capability of using 3G modems. Aside from his involvement in Sugar, he is the main author of a logistics system specially developed for the task of deploying 1-to-1 programs. This system has been made FOSS by Paraguay Educa and is being offered to other OLPC deployments.
* César D. Rodas (crodas) is not working on Sugar (yet!), but he has been assigned to make Fedora 11 run well on the XO-1 machines. This is very important for Sugar Labs, because until there isn't a new release for the XO-1, +1.5 million machines will be stuck with very old software: Sugar 0.82 and Fedora 9. This is also important because deployments start to feel empowered to take on tasks that were seen previously as too hard to be taken by anybody outside the OLPC headquarters.
Plan Ceibal
The Ceibal Plan is the name of the government project that has universalized computer access in primary education, Uruguay is the first country in the world to have achieved this and I'm happy that Sugar is the chosen software for each of the 366.000 machines. They have been modifying Sugar downstream to better adapt it to their needs, and have realized that by not upstreaming their work, it will be more expensive for them to update to new versions.
* Daniel Castelo (Daniel_C) has been put in charge of upstreaming their 3G modifications on top of the work that Martin Abente is doing. He is also working on adding printer support and has been thinking of implementing ADSL connections.
* Esteban Arias (esteban) has made excellent work adding accessibility features to Sugar and is now submitting them upstream. He's starting small for our next release (0.88) but he has lots more of very interesting stuff to upstream.
Though I find these developments very reassuring, I'm still quite a bit worried about the rest of the iceberg. If an organization deploying only 4000 machines is able to work internationally to develop the software to their local needs, which opportunities are losing the deployers of the million of machines that don't dare to participate in the development process?
There's also the issue of module maintenance: all Sugar modules are currently maintained by volunteers. When OLPC took maintenance of the 0.84 branch, they actually took work out from the shoulders of those volunteers, but the rest of the contributors are actually increasing the work that maintainers have to do because of feature discussion, code reviewing, bug triaging and stabilization. If the three volunteers that are maintaining most of Sugar run out of money and need to find a normal job, who is going to do that work?
Aside from module maintenance, there's also the roles of Feature Manager, Development team coordinator, Product Manager, System Administrator, etc. that need to be carried by someone. Deployments are going to need to participate in these other areas if they want to keep having a healthy place where to work together and pool their resources.
All in all, given what 2009 brought us, I'm thrilled when I try to imagine what 2010 has in for Sugar. Have a happy hacking year!
Saturday, January 16, 2010
A week at LATU (part III): More about developing with Sugar
Daniel Castelo kindly pointed out some important subjects that were discussed in my visit to Montevideo but I had forgot to mention in the last post.
Sugar Labs is providing a site where activity authors can post their activity bundles and Sugar users can search, download, rate, etc. This site is based on Mozilla's AMO which powers addons.mozilla.org, some more details in this older post. The colleagues at LATU asked about deploying their own instance, so they could better tailor what is offered on it to Uruguay's specific needs. I think that right now this is not a good idea because AMO allows us to display activities based on the Sugar version of the client and we can quite easily explain in the description or a comment if an activity makes most sense for a particular deployment. Also, AMO allows users to create collections of activities, so we could see collections specifically prepared for Uruguay classrooms.
We also dedicated quite a bit of time discussing the upstreaming of some features that the LATU has developed in-house, but I think this is more relevant for the community side of things so I leave it for the last post of this series.
Perhaps the most serious single issue I heard when asking for feedback there was that the XOs got sometimes in such a state that a full image reflash was needed. This means that any work that hadn't been backed up would be lost, which is quite bad if we consider that many kids won't have enough discipline (or media) to backup all their relevant work. I have been told that the first suspect cause is the internal flash filling up to a point where the machine doesn't boot any more.
Some ways of attenuating the problem are: making it easier to delete unneeded stuff from the journal by implementing selection of multiple entries, update to a version that doesn't leak temporary files, deploy school servers capable of accepting backups from the XOs and add a simple way to backup the journal to a pen drive.
The next and last post will be about what we discussed about how an organization like LATU can interact with FOSS communities to their best profit.
Sugar Labs is providing a site where activity authors can post their activity bundles and Sugar users can search, download, rate, etc. This site is based on Mozilla's AMO which powers addons.mozilla.org, some more details in this older post. The colleagues at LATU asked about deploying their own instance, so they could better tailor what is offered on it to Uruguay's specific needs. I think that right now this is not a good idea because AMO allows us to display activities based on the Sugar version of the client and we can quite easily explain in the description or a comment if an activity makes most sense for a particular deployment. Also, AMO allows users to create collections of activities, so we could see collections specifically prepared for Uruguay classrooms.
We also dedicated quite a bit of time discussing the upstreaming of some features that the LATU has developed in-house, but I think this is more relevant for the community side of things so I leave it for the last post of this series.
Perhaps the most serious single issue I heard when asking for feedback there was that the XOs got sometimes in such a state that a full image reflash was needed. This means that any work that hadn't been backed up would be lost, which is quite bad if we consider that many kids won't have enough discipline (or media) to backup all their relevant work. I have been told that the first suspect cause is the internal flash filling up to a point where the machine doesn't boot any more.
Some ways of attenuating the problem are: making it easier to delete unneeded stuff from the journal by implementing selection of multiple entries, update to a version that doesn't leak temporary files, deploy school servers capable of accepting backups from the XOs and add a simple way to backup the journal to a pen drive.
The next and last post will be about what we discussed about how an organization like LATU can interact with FOSS communities to their best profit.
Friday, January 15, 2010
Producing Open Source Software by Karl Fogel
Finally finished reading Producing Open Source Software from cover to cover. I found it very well written and full of stuff relevant to any FOSS contributor. I was surprised as I read how about 90% of the content matched what I had learnt by practice during the last 3 years. I'm very grateful to Marco Pesenti Gritti who passed all this knowledge to the Sugar team.
Anybody has had any experience giving this book for reading to people who still had no knowledge of FOSS?
Anybody has had any experience giving this book for reading to people who still had no knowledge of FOSS?