Johan Dahlin

Launching Stoq 1.1

We’re launching Stoq 1.1 today, which is a POS/CRM/accounting/industrial application mainly for the Brazilian market. In short the kind of software you’d use in a supermarket, bakery, cloth shop, manufacturing company etc.

It’s written in Gtk/Python/PostgreSQL and is available for Linux/Windows. Free software (GPL), stable, fast and beautiful!

New for this release is the reorganization of the applications to always fit into one window (conceptually similar to evolution/outlook) and a new application selector which should make it easier to switch between different parts of the app.

It’s fully translated and can be used outside of Brazil, even though a few small details are oriented around the fiscal requirements set by the brazilian government.

There’s a livecd available on Ubuntu, so you can just download it and try it out.

For more information see http://www.stoq.com.br/

Interview in Portuguese

A couple of weeks ago I did another first – a recorded interview in Portuguese, thanks to the great host Og Maciel.

I had a great time and we talked about my involvement in GNOME, Stoq together with a bunch of other random topics, check it out at:

http://www.castalio.info/johan-dahlin-stoq-gestor-comercial-livre/

Using LLVM to speed up function invocation in a dynamic language binding

With the recent release of PyGObject I decided to take a look into something I’ve been meaning to do for some time, using the excellent LLVM library to make things go faster.

But first some brief history. Back in the old PyGTK and pygtk-codegen days all functions were created at compile time generating all the Python<->C wrappers that you would ever need. This is problematic for various reasons:

Bridging the development gap between desktop and web

One of the reasons JavaScript was chosen as the language for GNOME Shell is as Owen mentions: “… a lot of people are familiar with it from the web.”. It’s not a new idea but certainly an exciting one. Who wouldn’t want to be able to run their desktop application on the web or their web application in a desktop environment?

A fairly common complaint about Gjs is that it’s not possible to use cairo from it. Cairo bindings were recently committed to Gjs, but I didn’t quite find the time to write a couple of nice applications demonstrating how to use it. But instead of writing my own blingy cairo application I thought, wouldn’t it be nicer if I could just take a canvas demo from the web and with minimal modifications run it on top of gjs with cairo?

The missing piece to that goal is a HTML5 Canvas & CanvasRenderingContext2D API on top of the cairo binding. After a couple of bug fixes in gjs I got it to a point where I could run a slightly modified version of a simple clock example in gjs:

The screenshot aboves shows the same code running in the browser to the left, in HTML. To the right is the same code running on top of Gtk+, before you ask, the source code can be found here on my github page. If you want to run this you’ll need patches from these two bugs applied first.

There are a couple of other APIs that would be nice to have in Gjs such as DOM, Storage, WebGL. I didn’t try to implement these, but let’s hope someone does so the GNOME developer environment can provide familiar apis for the huge pool of web developers out there.

News from the introspection world

There has been a number of recent developments in the world of introspection, let me summarize some of them:

First of all, the litl got uncovered and released a couple of weeks ago. The whole litl software platform is heavily dependent on the introspection parts and on the gjs, the spidermonkey javascript bindings. It’s been a great experience of easily being able to move code between javascript and C as we see fit. Adding a new method to a GObject class in C is just a make a away from making it available to the javascript bindings. Lucas and Scott have written more about the technical parts of the litl.

Gjs has recently gained callback support, which has been kind of a personal pet peeve for me. Making sure that functions and methods with callbacks are possible to call from a language binding has always been difficult. GClosure sort of solves that problem, unfortunately very few libraries actually use them. Most of the tricky work of landing callback support in Gjs was done by Maxim Ermilov, rock on!

The Python bindings are also moving along pretty quickly. Tomeu Vizoso and Simon Van Der Linden has been working aggressively on making them solid. The rumor tells me that Tomeu has the whole OLPC Sugar interface running on top the new bindings, with significant speed and memory improvments!

Elliot Smith at Intel blogged about his experiences on using Gjs on Moblin developing a clutter application. Zach Goldberg writes about his experiences on adding callback support to the python bindings.

More and more libraries are adding introspection support, the latest ones are libgda and moblin toolkit.

litled

Today is my first day at litl. I’m joining a team which should be familiar to GNOME:rs in general: Johan Bilien, Lucas Rocha, Havoc Pennington and Tommi Komulainen. Exciting times!

Introspection hackfest at the Boston Summit

We’re arranging an introspection hackfest at the Boston Summit! Thanks to the nice lads at the foundation we can have most of the participants flown over. Colin Walters, Jürg Billeter, Philip Van Hoof, I and hopefully Havoc Pennington is going to be there.

If you’re interested in language bindings or other uses of the introspection data, come by and help us out.

Oh, I almost forgot to say hi to Planet Python. Andrew was kind enough to add me there. My name is Johan Dahlin and I’m mostly working on Python related to GNOME, especially, Python bindings for GObject and Gtk., and Kiwi + Stoq of course. The introspection project is intended to make it easier to write language bindings for the Gnome stack, not only Python ones.

Generic CClosure marshaller using libffi

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

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

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!