Ubuntu 5.04's Nautilus crack (close windows when you open a new one) is intensely irritating. I hope they fix this before shipping CDs. Otherwise, it'll really spoil people's first impressions of GNOME, and it'll be difficult to be so enthusiastic when giving them to people.

I'm not sure how the decision was made, but I'm pretty sure that someone should have listened to Jeff, who I guess would never have wanted such a dangerous change at that point in the release cycle. And just when Ubuntu was being a poster-child for release sanity.

Glom's calculated fields can now calculate useful stuff, though so far they only have access to fields in the current record. Obviously the syntax needs to be more compact.

This requires pygtk and the libgda python bindings, not yet released in a tarball. I added them to gnome-python-extras after Filip Van Raemdonck did most of the work. The guys in the #pygtk irc channel, notably Johan Dahlin and Gustavo Carneiro, were incredibly helpful with my pygtk and embedded python questions. Glom is certainly the only project that depends on both gtkmm and pygtk.

I stopped using boost::python. It's just too much trouble to build inside Glom, is overkill for what I need, and I'm not convinved that the API is all that sane anyway. I've made some notes that I'll send to their mailing list. In particular, I don't think it's healthy for it to be constrained by boost's lack of API-stabilty given that boost::python (unlike the rest of boost) has zero chance of becoming part of the C++ standard library. It might be a healthier project in the wild. However, lots of people do use it.

I really like to share a big apartment for GUADEC this year. That worked really well in Seville when Daniel Pisano found a place for us. But so far I can't find a suitable agent or a real Mitwohnzentrale in Stuttgart.

Last night I couldn't sleep, so I added some convenience functions to GtkTreeView. This would make the API easier for the common cases, and easier to get started with, but the gtkmm TreeView API is still better.

The GNOME Deutschland blog planet now has a permanent home – planet.gnome-ev.de.

It took a while because I had to fight against various bad SUSE defaults. I don't understand why anybody would use software that (apparently) has no public bug database.

I'm now the interim vice-chairman (or some similar translation) of the GNOME Deutschland “foundation”. Christian Meyer is now the chairman, and the official public voice of GNOME in Germany. He's done heaps of work to get the e.V. (foundation) started and for GUADAEC too.

Here's what I plan to do. It's mostly about the website. Hopefully we can bring together all the hard work already done by the community and build something much bigger.

I'm already on the regular GNOME Foundation board. Maybe I can collect them all. I think the board is doing well so far. We are not being distracted by irrelevant stuff and we're delegating where appropriate, allowing us to finally nail the trademark issue, publish the finances, and get started on merchandising, among other things.

I added numeric formatting to Glom, so you can have currency symbols, fixed decimal places, and avoid thousands separators.

For the list of currency symbols, Glom now depends on iso-codes, which provides the symbols and names, and gettext() translations for them. There are country and language names too.

This also reminded me how unpleasantly obscure numeric formatting of streams is in C++. But I got it working.

Now I am looking again at the calculated fields, thinking of integrating the python libgda bindings with my C++ code, so I can pass some of Glom's libgda objects directly to the embedded python interpreter.

I am also exploring the C++ boost::python library instead of using python's C API directly. The API is unstable, so I must copy a huge number of boost files into Glom itself. So far it looks quite odd (lots of preprocessor macros), but I'll be happy enough if it works.

I've mostly dealt with another big to-do item for Glom. I added Users/Group administration, with per-table access rights for each group of users.

The changes touch most of the code, so that all parts of the UI just do the right thing, so I'm sure that I've introduced several bugs. After all this work, I will reward myself with a few more episodes of West Wing.

I implemented another important feature in Glom – related fields, which allow you to see, and edit, a field in a related table. And the related record for the related field can be created automatically when you enter data into the related field. This should be very familiar to FileMaker users.

So what's next? Maybe numeric field formatting options, or user administration, or maybe making python-calculated fields really work.