Day: August 6, 2007

Jürg Billeter finally has his blog setup. He finished the first building blocks of a DBUS binding for Vala and made a sample. Go check it out!

Vala

A lot of people are visiting #vala on GimpNET to tell Jürg Billeter how much they like Vala. One such person already finished a Vala binding for GtkMozEmbed, another is now working on bindings for Clutter.

This is very cool indeed. Soon we’ll have solutions in place for the vast majority of our libraries. I hope our community realizes that the emerge of a new programming language can only succeed if the creators get some help with implementing required instrumentation.

There’s for example a challenge in supporting .vala files in a clean way in autotools and Makefile.am. Although the majority of people dislike autotools & co., it’s used by nearly all of GNOME’s libraries. To make things work smoothly is a good integration needed. The difficulty is that a Vala compiler, unlike a C compiler for typical C projects, needs a list of all Vala files to start generating the .c files. For Python they needed something similar using a helping script called py-compile. Java can cope with a file per class, as there’s a file-name convention.

Vala is missing documentation, a website and there’s a lot of low hanging fruit that can very easily be picked up by new people.

As for Tinymail, me and Jürg are planning to replace the TnyList and TnyIterator interfaces with the ones in libgee sooner or later (probably later, as I’d like to release a one point zero of Tinymail before that). I heard the Anjuta folks are interested in replacing their “from IDL generated interfaces” with Vala-ones too. I might just bite the bullet and rewrite all Tinymail’s interfaces in Vala. As soon as Jürg has the binding generation for Vala in place, that would mean I would get the generation of language bindings for free. Right?

This illustrates why I think Vala is such a good idea. Especially for GObject based libraries that have interfaces for their API.

Tinymail

Today I finished the work on Tinymail to make it completely “Gdk lock” aware. This means that Tinymail’s signals, observer update invocations and callbacks are all “Gdk lock” aware. In practise this means that you, as application developer, don’t need to acquire the Gdk lock yourself. For your own timeout and idle callbacks and for your own threads calling Gtk+ or Gdk subsystems you of course still need to do this.

This work will be committed tomorrow. I don’t know when Modest’s public repository will have the required changes for this (some people are on vacation, etc etc).

Documentation still has the top priority at the Tinymail project, so some new documentation items got added. Mostly about how Tinymail works internally related to the recent improvements. I have asynchronous operations, asynchronous connecting and dealing with the Gdk lock for you.

These recent improvements combined together should make Tinymail more robust against threading problems. There’s locking order, queuing and guaranteed handling of the Gdk lock in signals, observer update invokes and callbacks. The queue waits for the return of the callbacks made by the application developer, avoiding that the application developer can launch a method in that callback that would lock with the original call that invoked the callback. Lot’s of improvements like that.

All these things have delayed the release candidate that I promised to some people at GUADEC this year. I also want to let the improvements stabilize a little bit. On top of that there’s quite a lot of work cleaning certain things up. I would also like to create a QEmu image with an IMAP server and the Tinymail demoui that I’ll release in parallel. These are certainly things people can help me with, if they want me to speedup a release for Tinymail.

The make distcheck should be again working, some of the unit tests need reviewing, the !@#*@* gtk-doc scripts need to be fixed .. again, the !@#*@* Python bindings are broken .. again, the enum and flags GTypes are synchronized once more (although some don’t have documentation in gtk-doc yet), etc. I guess all these are the typical 60% of work a project maintainer has to do. A lot of work is indeed because all our development tools are completely broken and not integrated with how people really work.

Gdk Lock aware?

Right, some people have reviewed that wiki page that I mentioned yesterday. Hoping more people will do reviews.

IRC

If you can’t join a GNOME or Gtk+ channel on GimpNET because it’s invite only: /msg dorito invite #channel. The ops had to set some channels to invite-only because of spam bots.