Session on GObject Introspection at the Ubuntu App Developer Week

The talk will be oriented to developers that use or want to use GNOME technologies and still haven't fully grasped how GObject Introspection is changing the game. It won't contain any distro specificities, so join without fear even if you don't use Ubuntu, if it's of your interest.

It should be of special interest to those willing to contribute to GNOME Shell or that plan to attend Martin Pitt's talk about life after PyGTK this Tuesday at 16 UTC.

You can find instructions about how to join in the link below, plus other interesting talks:

https://wiki.ubuntu.com/UbuntuAppDeveloperWeek

See you later today at 17 UTC.

GNOME 3 at Prague

Tomorrow we'll hold a GNOME 3 Launch Party here in Prague and between interesting and even controversial talks, I will be talking a bit about the changes in the development story that happened during GNOME 3.

http://live.gnome.org/ThreePointZero/LaunchParty/Czech

See you there!

GObject-Introspection hackfest

Following the success of the two last PyGObject hackfests, the idea of having one focused on GObject-introspection has been floating for a while.

After enough people agreed it could be a good idea, I have created a page in the wiki to start filling in the details. We should have a good provisional list of goals and participants before we get to things such as the place and date, which will be better decided once we have the participant list.

http://live.gnome.org/Hackfests/Introspection2011

So if you are planning to do some work on GObject-introspection that would benefit from happening in the hackfest, please add it to the goals list in the wiki.

If you won't be able to work on it yourself but you think something should really happen in the near future, please add it to the comments in this blog post.

I know we can count on consultancies such as my employer Collabora to sponsor the hackfest, but I would like to encourage downstreams to send their hackers and show they care, are able and deserve more good will.

Generating API docs from .gir files

From time to time people ask which are the plans about generating API documentation from the introspected information in the .gir files that g-ir-scanner outputs.

More often, I hear someone swearing about how hard is to setup gtk-doc to correctly generate documentation for your code. And getting g-ir-scanner to generate .gir files as expected is not completely trivial either.

It should be apparent that generating the docs from the .gir would save quite a bit of grief altogether but for one reason or another this hasn't happened yet. Docstrings are in the .gir files already along with the rest of the metadata but gtk-doc is still scanning the C sources.

© Juan José Sánchez Penas

During last GUADEC, the gobject-introspection people could be seen hacking in the lobby instead of attending your talk or rioting against the release team, and one of the outcomes was Zach Goldberg's g-ir-docgen script. His new employer forbids doesn't sponsor him for this work so this has been in the freezer since then.

So we can eventually get out from this situation, I would like to encourage interested non-coding people to add to CC on this bug: https://bugzilla.gnome.org/show_bug.cgi?id=625494

And to those that can actually code, please consider using that ticket to coordinate the effort, it may take less work than you think and it can be a fun hack. Think of all the GNOME hackers that will thank you!

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.