PyGObject 3.0.3 Released

The Sugar guys are doing great progress porting their code from PyGTK+ to GObject Introspection and they have requested a new stable release, which comes with these goodies:

- Convert all modifier constants to Gdk.ModifierType (Manuel Quiñones)

- Convert all strings to utf-8 encoding when retrieving from TreeModel (Sebastian Pölsterl)

- add test for bytearray variants (John (J5) Palmieri)

- handle NULL arrays correctly for each array type (John (J5) Palmieri)

- Revert "Revert "Fix array termination and size calculation"" (John (J5) Palmieri)

- pygmainloop: avoid lockups if multiple glib.MainLoop exist (Owen W. Taylor)

- Properly chain up to the class that implements a given vfunc. (Tomeu Vizoso)

- Revert "Fix array termination and size calculation" (Tomeu Vizoso)

- Fix array termination and size calculation (Holger Berndt)

- pygi-convert: fix for Pango.Alignment (Daniel Drake)

- pygi-convert: fix for Gtk.Orientation (Daniel Drake)

- Add tests for calling closures (Martin Pitt)

- fix marshaling of arrays of GVariants (Mikkel Kamstrup Erlandsen)

Thanks all for your hard work!

PyGObject BoF at the Desktop Summmit 2011

A BoF has just been proposed for the Desktop Summit in Berlin in August, this is the description:

We'll get together to port applications from PyGtk+ to Gtk+ 3 (using GObject introspection). Seasoned developers of PyGObject will meet applications developers and will help each other port applications and improve PyGObject itself.

The session is still just a proposal and we'll only know if it has been accepted in a few days, but if you will be at the Summit and this session interests you, please feel free to add yourself to the list of prospective participants.

See you in Berlin!

Wrap-up: Python ⊕ GNOME Hackfest 2011

A bunch of GNOME hackers spent the last week hacking on the Python bindings and this post gives an account of the achievements and tries to give credit where is due.

First, all attendants made substantial contributions and they and their employers (if not volunteers) should be thanked by their commitment: John (J5) Palmieri (Red Hat), Sebastian Pölsterl (volunteer), Laszlo Pandy (volunteer), Simon Schampijer (OLPC), Ignacio Casal Quinteiro (volunteer), Steve Frécinaux (volunteer), Simon van der Linden (volunteer), Martin Pitt (Canonical), Pavel Holejsovsky (volunteer) and myself (Collabora).

Also, Johan Dahlin (litl), Colin Walters (Red Hat), Paolo Borelli (volunteer) and Mikkel Kamstrup (Canonical) joined us remotely to hack together.

In numbers, at the hackfest were pushed 72 commits to PyGObject, 13 to gobject-introspection and 21 to Gtk+. There was quite a bit of Bugzilla activity as well.

One of the highlights was the push of *lots* of annotations into Gtk+, work submitted by Pavel and reviewed by Johan and some hackfest attendants. This makes a big part of the Gtk+ API accessible through introspection but there will be bugs so testing and corrections are still needed.

Another important contribution has been Martin's work on improving the GVariant and GBus API as exposed by PyGObject. He has a nice blog post explaining his work.

Steve did an amazing job delving into the ugliest innards of PyGObject and fixing some really hard memory leaks. Also, he added several test cases for other reference counting conditions which will help with not breaking it in the future.

Among other things, Laszlo worked on preserving GError information when propagating exceptions to Python and also has been looking at improving considerably our startup speed.

John kept hacking on his rewrite of the invoke path, including all argument validation and marshalling, so we get closer in speed to the static bindings. He gave a presentation explaining his strategy and people in the room seemed to like it. I expect a blog post from him soon on this subject.

Simon (svdlinden) did a lot of bug triaging, code reviews and rationalized our build system, needed after years of regular maintenance hacks.

Sebastian worked mainly on adding overrides, annotations and improving the perl script we provide to make porting easier. This as part of his porting of DVB Daemon to Gtk+ 3.

Nacho kept porting GEdit plugins to introspection and submitted misc. patches as he went, both to core PyGObject and to overrides.

Simon (erikos) started porting some containers in Sugar to Gtk+ 3 with great enthusiasm, but he found that the recent API changes in Gtk+ weren't supported by PyGObject nor gobject-introspection. Several fixes went in and others are still travelling through Bugzilla.

Johan and Colin helped out with reviews and answering our questions about how best to fix things in gobject-introspection, Paolo was there spotting any problems with the code that was being checked in and Mikkel was porting an Ubuntu app and reporting issues.

To finish, I spent most of the time reviewing and discussing approaches with the others but also managed to find some time to do some actual coding myself. Hope to find time during this week to push the last patches through bugzilla and make a new release with all that good stuff.

I'm pretty sure I have forgotten to give credit about something to someone so I apologize in advance and will gladly update this post if I'm told to :)

Thanks to Collabora for sponsoring the hotel, coffee, everynight's beer and the nice duckfest on Thursday at the U Slovanské lípy, check out the photos below:



The GNOME Foundation sponsored the travel and lodging for the participants of the hackfest:

We are also very obliged to the people at the brmlab hackerspace who hosted us during the whole week, they were really great:

Python ♥ GNOME Hackfest 2011

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.

The cost of doing your own shell on top of GNOME

In this post, Dave Neary writes:

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.

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.

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.

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.

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.

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.

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.

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.

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:

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

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.

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.

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.

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:

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.

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!

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

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