Generic CClosure marshaller using libffi

GNOME, General, PyGTK, Python, olpc 1 Comment

Marco: You can also use the libffi CClosure marshaller I wrote for PyGObject. If you use you don’t need to generate the marshal.list at all, it’ll figure out the signature and call the callback just by looking at the signals GValues.

I originally wrote it so that Edward could prototype playbin2 in gst-python and still being able to connect to signals created in python from GstElements written in C. I know that a couple of other projects are using that file by copying and pasting it while waiting for bug 401080 to be solved.

PyGObject activities

Blogroll, GNOME, General, PyGTK, Python, olpc 1 Comment

I’ve been spending quite a bit of time lately on PyGObject, the python bindings for GObject. This blog post will summarize the recent activies.

Code Generator move

One of the most important parts of the gtk python bindings lies within the code generator. This piece of software which was mostly written by James Henstridge, Gustavo Carneiro and I takes an API definition file (in scheme s-expression style) and output C glue which tell Python how to call the API in a library. For various reasons the code generator is mostly intended to be used by a GObject based library. It was originally written for PyGTK but has since been used in a number of other placs, most noticable gst-python contains a fork which various modifications. It has recently moved from the PyGTK package to PyGObject and can now easily be used by GObject based library which wishes to use it without depending on GTK+.

GIO

The principal motivation for moving the code generator from PyGTK to PyGObject was to be able to create GIO bindings. An initial set of bindings has been created for GIO. They are not complete yet, quite a bit of the API which takes async result parameters has not yet been written, but it should be perfectly usable by applications already. Please use it and let me know if there is any methods missing and I will gladly wrap them for you

GLib

One of the complaints over there years has been that it’s kind of weird to type gobject.MainLoop(), gobject.io_add_watch() etc, since these functions are not really related to GObject. Complain no more, they have now moved to a new module called just glib. It’s been quite hard to come up with any reasonable use cases for third party packages using glib but not gobject. I guess one of them is python bindings for Qt wishing to integrate with the python bindings for Gtk+. Qt already provides (optional) glib/mainloop integration, so perhaps this would be useful to them.

Porting to Python 3

This weekend I ported the glib and gobject modules over to be compilable against Python 3.0b2. It has been done in such a way that the source code is compatible with both the 2.x and 3.0 APIs of Python. To be able to do that I was forced to add a number of quite intrusive macros which takes care of the hard work. I’ve only managed to reach the point where it is possible to import the gobject module. The code generator and the gio bindings has not yet been ported. Even less has the testsuite been run, so this is just moderatly useful at this point. As part of porting this I had to make the python support in automake be compatible with python 3. Patches against git head of automake can be found here.

GIO python bindings

Blogroll, GNOME, General, PyGTK, Python, olpc 7 Comments

Late yesterday evening I did a new release of pygobject. The first one in about 10 months, I should do this more often I know. The most important thing featured in this release is the addition of GIO bindings. I know lots of you out there have been asking for this.

There’s still no official documentation included, but there’ll be in the near future as we have a couple of people working on it. While you wait, enjoy this simple example:

import gio
fp = gio.File("http://planet.gnome.org")
data = fp.read()
print data

We have also moved the code generator from PyGTK into PyGObject, this means that GObject bases libraries can be wrapped in python without having to depend on GTK+, this should be quite useful, I think.

I’d especially thank Paul Pogonyshev (doublep on irc) for this work on this release, he’s getting more and more involved in both PyGTK and PyGObject, thanks Paul!

Simplified tabbing support in Gtk+

GNOME, General 15 Comments

There has been a couple of posts recently on Planet GNOME mention the increase usage of tabs in applications. I decided to write up a quick patch for GTK+ which makes it even easier to add tab support. With the patch I applied you can just call a single method:

gtk_widget_set_use_tabs (widget, TRUE);

To get complete tab support in your application.

Emmanuele just reviewed it and it will soon be committed to SVN trunk of GTK+. I’m looking forward to applications migrating to this new simplified API!

Monday Quiz

General 10 Comments

In this quiz I am looking for 3 persons who are or have been syndicated by Planet GNOME.

Question 1: What are their relationship with the below mentioned projects/technologies?

Question 2: Who are they?

Person A

  • Norton Commander
  • Microsoft COM
  • Microsoft .NET Framework
  • Microsoft Excel
  • Microsoft Outlook
  • Microsoft Silverlight

Person B

  • Regedit
  • DCOP
  • KHTML

Person C

  • Apple iTunes
  • Spice3
  • Microsoft Project