It's a sweet project

Open GNOME/Sugar position in Greece

2010-09-07T12:37:00.005+02:00

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:

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

PyGObject matching GLib version numbers

2010-08-11T10:42:00.002+02:00

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.

GNOME beer event in Prague

2010-07-18T12:30:00.002+02:00

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.

Python and introspection are in Fedora

2010-07-08T09:05:00.003+02:00

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.

New PyGObject release: 2.21.4

2010-06-29T12:01:00.002+02:00

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:

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

PyGI has been merged into PyGObject

2010-06-28T13:38:00.003+02:00

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.

Proposed GNOME goal: Port your PyGTK to the new PyGI bindings

2010-06-19T10:01:00.003+02:00

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:

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.

New PyGObject unstable release: 2.21.2

2010-06-11T09:45:00.002+02:00

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


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

PyGI now in Debian and Ubuntu

2010-06-07T13:39:00.004+02:00

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!

New PyGI release: 0.6.0

2010-06-04T11:12:00.003+02:00

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 (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

New Python list at gnome.org

2010-05-25T08:50:00.004+02:00

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:

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

Telepathy and Ubuntu

2010-05-17T14:06:00.002+02:00

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:

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

2010-05-17T13:01:00.005+02:00

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.

Two talks in Greece about Sugar

2010-05-07T18:54:00.003+02:00

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.

Going to UDS-M

2010-05-05T10:04:00.004+02:00

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.

Using telepathy-glib in python through gobject-introspection

2010-05-05T09:13:00.004+02:00

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:

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.

The 2010 Python GNOME hackfest is done!

2010-04-19T17:05:00.006+02:00

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/

Python + GNOME hackfest is set

2010-04-07T18:07:00.004+02:00

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.

Sugar with better Telepathy

2010-03-19T18:40:00.004+01:00

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.

Update on the Python/GNOME hackfest

2010-03-06T11:14:00.002+01:00

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.

Early childhood hackers

2010-03-03T11:17:00.003+01:00

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:

...
- 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.

My focus during 0.90: Collaboration

2010-03-02T18:05:00.005+01:00

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.

Make Your Own Sugar Activities!

2010-02-26T17:20:00.002+01:00

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.

Visit to Igalia

2010-02-24T17:16:00.006+01:00

New Igalia office by

Berto Garcia under CC BY-SA 2.0

A couple of weeks ago I spent two days with the colleagues at Igalia, talking about Sugar and other GNOME stuff. The goals were to brief them on the current state of Sugar - from the technical, community and business points of view, and to discuss ways in which they could contribute to this adventure of using computers to improve education everywhere. As a company, Igalia has a strong interest in Sugar because of their social mission, which they take very seriously, and also because of their 8 years of GNOME, Freedesktop and Linux experience, which allows them to jump into Sugar without further investments.

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.

Tomeu Vizoso in Igalia by

Mario Sánchez under CC BY-SA 2.0

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.

Hacking session on sugar, by Tomeu Vizoso by

Andrés Maneiro under CC BY-SA 2.0

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.

Free love

2010-02-15T13:18:00.002+01:00

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.