Well it has been awhile since we had the awesomely productive GNOME Python hackfest and now we have a roadmap and people working on getting out releases of the various components. At first I came in as a concerned citizen who just was just a consumer of the Python stack. I thought I would just organize a hackfest, attend a couple of days and everything would work itself out. I find naiveté helpful when getting started in a project because if I walked in knowing the amount of work involved I would start whistling, make a sharp U turn and hope nobody noticed me running for the hills.
As it stands I am lucky enough to have a Manager who realizes the importance of the GNOME Python stack (given that a lot of Red Hat’s tools including the installer are based off of them). Fedora 13 already has a parallel installable Python 3.1 stack and since we are targeting Fedora 14 to get as many major modules ported as possible, I have been give permission to work full time on the GNOME bits.
So what exactly have I been up to?
I’ve been working on porting PyGTK apps to PyGI with an eye towards fixing up the PyGI API through the overrides, finding and fixing bugs and adding binding friendly API’s directly to GTK+ (as well as fixing up some of the introspection annotations).
Where am I at?
I am happy to say that yesterday I managed to squash what seems to be the last of the memory crasher bugs that have been frustrating my API fixing efforts. They still need to either be vetted or are waiting on other patches to be incorporated into git so for now you can apply the patches in bugs 617780, 618049, 619007 and 583909. Actually the last two patches are redundant, the latter being the correct patch and the former being the patch we will go with if pygobject take some time to approve. PyGObject is a lot more risk averse since the PyGTK static bindings also relies on its API being stable.
I am also pretty sure that most of the GtkBuilder/GtkUIManager stack is now usable with minimal porting efforts from PyGTK. I should be pushing most of my override work into git fairly soon (I need to write test cases). One issue is they rely on patches to GTK such as the one in bug 61857 which won’t be in GTK until the 3.0 release. This leads to another issue of finding all the needed API changes. Since GTK is on a 9-12 month release cycle, not to mention API freeze dates, it might be hard to find all the API that needs adding in order to be binding friendly. Bellow I will talk about some strategies to deal with this.
What needs to be done and where can others help?
The biggest hurdle to making PyGI usable is gaps in API coverage. Because PyGI’s API is mostly auto-generated on the fly it doesn’t always get things right or throws in a lot of C’isms which are confusing in a Python world. Some APIs just plain can’t be wrapped correctly and will lead to refcounting errors and ultimately crashes. PyGTK on the other hand has been developed for many years and each API has evolved to fit within the Python world. Some are APIs better wrapped than others but I digress. What needs to be done is port small PyGTK examples that utilized different parts of the GTK+ API. For things that don’t work we need to file bugs and write overrides for those pieces of API. We are not aiming for a 1 to 1 port of PyGTK. For instance PyGI’s handling of constants, enums and flags is much nicer and more complete than PyGTK. What we are aiming for is to make it easy enough to port applications and to be able to fully utilize the GTK API.
As for patches to GTK goes I think we should have a two pronged approach. We should create a compat library that adds the needed API fixes but prefer API inside of GTK itself. The compat library will be for internal override use only and anything going into the compat library must first have a bug and patch filed against GTK. As we get a larger coverage inside of GTK, all new GTK APIs are vetted for scritability issues and distributions start removing support for older versions of GTK we can drop the compat library.
We also need people to read and vet patches as well as usher them through the approval process. Getting patches through quickly to meet schedules is very important. Helping to write tests for patches will also speed up the approval process.
Do I see any roadblocks in the way?
My number one biggest concern is the Tree and List model/view API. It is packed with C’isms so requires a lot of hand holding to wrap correctly. Also PyGTK has a rich, completely custom, tree API because of this. That means for the most part we have to hand write and maintain a lot of code in order to get the API into a usable state. I already took a crack at it but got frustrated when trying to wrap parts that used iters. It is all doable but in the end even PyGTK had to make some hard decisions (using TreeIters will almost certainly cause a leak). Does anyone want to write a new script friendly Tree API? I find this issue to be the dragon standing in the way of getting PyGI to a usable state. Let’s just hope it doesn’t turn into a windmill.
Where can someone ask questions and offer to help?
Right now the best place is #pygi on GIMPNet/irc.gnome.org. We are in the process of creating a mailing list and will inform everyone once it is up.
[read this post in:
ar de es fr it ja ko pt ru zh-CN ]
