Did some more hacking on my Python bindings for Cairo. They are now in the new freedesktop.org CVS server.
I added a cairo.gtk.set_target_drawable() function that sets a Cairo context to draw on an arbitrary GdkDrawable, taking into account the temporary pixmaps used by GTK for its double buffering and the expanded virtual 32-bit coordinate space (based on some of Carl’s code in grrobots).
I ported a few of the Cairo demos to Python/GTK for testing purposes, and they all seem to be working fairly well. The exception is the knockout demo, which doesn’t seem to be redrawing properly (a bad interaction between Cairo and GTK’s double buffering, I guess).
Been discussing the bindings on the Cairo mailing list. I’ll probably be merging my bindings with Maarten’s ones.
I also brought up a few changes that would make it easier to write robust language bindings. Since the API is fairly new, the changes will probably go in.
LWN covered the pygtk 2.0.0 release. 2.0.0 is also in RawHide too, so it looks like it should be a usable baseline in the near future.
In CVS, the move on to GTK 2.2 APIs is under way. It is still necessary to test them, and add a few custom overrides, but things are looking fairly good. The wait for 2.2.0 shouldn’t be anywhere near as long as the 2.0.0 dev cycle
Started on some Cairo bindings for Python. At the moment, they are fairly immature, but shouldn’t require too much more work before I can test them.
Differing a bit from the C API, I’ve made the cairo_matrix_t type immutable from Python. That is, all the operations that modify a cairo_matrix_t have been wrapped in such a way that they return a new matrix rather than modifying the old one.
I also set things up so that cairo_status() calls are made automatically after operations, and an exception rasied if appropriate.
The next thing to do is to set up some shim code to make the binding usable in conjunction with PyGTK. This will probably just be a bit of code in an extension that lets you create a cairo.Surface from a GdkDrawable or GdkPixbuf (in 24-bit RGB format — since GdkPixbuf uses RGBA and Cairo uses ARGB, it doesn’t look trivial to render into an RGBA pixbuf).
Talked with keithp on IRC a bit about the extension, and some changes to the Cairo API that would make the extension’s life a bit easier. Will follow it up on the list.
As predicted by the anti-virus firms, it looks like Sobig.F has stopped propagating (based on the sudden drop in virus bounce messages I have been receiving). About time.
There was a really weird interview on Lateline last friday. They now have the transcript. Christopher Pyne really reminded me of Dexter Pinion from Backberner.
Looks like the government put up a website for one of the weirdest community service announcement I’ve seen in a while. I wonder if they intended to make it as funny as it seemed?
A story was posted on FootNotes about the 2.0 release. A number of nice comments. The 2.0.0 package has hit Mandrake cooker, and a Fink package is apparently in the works.
I’ve started work on adding support for the GTK 2.2 APIs, which shouldn’t take very long at all. I’ve updated the .defs files, which covers most of the APIs. There are some others that will require a little more work.
PyGTK 2.2 will be a drop in replacement for 2.0.0 when it is ready, just as GTK 2.2 is.
Only 5 days til I stop receiving bounces from the sobig worm! I had hoped that people would fix their mail servers, to not send out these erroneous bounces, but no such luck
I wonder when the next one will strike?
The new series of CNNNN started a couple of weeks ago. Been pretty good so far. I don’t think it is the kind of show that they could syndicate overseas though
Finally got version 2.0 of PyGTK, PyORBit and Gnome-Python out. I sent the announcements a bit further than usual this time (gnome-announce-list, python-announce, etc). Already, it is in Debian, Mandrake Cooker and there is a Win32 installer. PyGTK is also buildable/runnable on MacOS X, provided that you have an X server installed (such as Apple’s one). If you have been holding off from looking at PyGTK 1.99.x, you should definitely take a look now.
This release has been a long time in the making:
- 595 revisions to the ChangeLog (out of 670 revisions on the main branch in CVS) since branching the 1.2 bindings.
- Over 5000 lines in the ChangeLog.
- Over 3 years since branching.
The result is a binding that is a lot nicer to use, and will be much easier to maintain. It does demonstrate that you lose a lot of time when you decide to do a rewrite. At the same time, I don’t know if it would have been feasible to get from the old 1.2 bindings to where we are now in small incremental steps. I am very happy with what we have now though.
Updating the binding for GTK 2.2 (and GTK 2.4 after that) is going to be a lot easier and quicker. All the infrastructure is in place, so it is a simple matter of adding the new APIs. The 2.0 to 2.2 delta is much smaller than the 1.2 to 2.0 delta.
It is a similar story for the Gnome bindings, although we will probably skip to Gnome 2.4, since it is almost out and contains some new APIs that are interesting from a language bindings perspective. I won’t need to rewrite the CORBA bindings this time either .