Testing weblog-add.py so I can create pyblosxom entries through the silly firewall.

I'll be working in Berlin for the next six months or so, starting Monday, getting back to Munich as often as possible. This is awkward, but makes some other things possible.

Even more than usual, this means that people need to help themselves with my various open-source projects. Patches will be reviewed and committed, and test cases will be pondered during 6 hour train journeys.

I think that the GNOME 2.7/2.8 API/ABI freeze is on Monday, so I'm trying to wrap the extra gnome-vfs DNS-SD and resolve API for gnome-vfsmm.

I released another version of glom today, which adds some signifcant new functionality and fixes a lot of bugs that had worried me. I've been doing releases almost every week because I find that helps me to focus on adding features and then bugfixing them, rather than just hacking at random. I'll probably slow down though, because I feel I've achieved enough for now. I know what needs to be done next, and I know I can do it when I feel like it. Also, I won't get much feedback until it can be packaged widely, and that can't happen for a few months yet. It's been very enjoyable to develop something with a clear idea of what I want, and without pressure.

The next big tasks are:

• Make the Details layout a set of heirarchical multi-column groups, so that groups of fields can span all columns, and to allow lists of related fields to be shown among the regular fields.
• Derive a custom TreeModel that gets clumps of data from the database just-in-time.
• Allow constantly-updated calculations with Python.
• Think up some way to define print layouts, with headers and footers and repeating sections, and groups and summaries.

Today has been quite successful. So that field values can be calculated from other fields, I have embedded the Python interpreter into Glom. This should give people a lot of freedom to play with their data, and to get special information such as the current date/time. I might even use it for scripting, like in Filemaker, so that people can put buttons on their layouts to make stuff happen. And people could use pygtk to interact with the user.

John Ehresman on the #pygtk irc channel was very helpful with this.

I also need to provide the field values to the python environment, so that the script has some data to work with, but that looks quite straightforward.

Julian Missig has decided to stop work on gabber, because he has a crashing bug. He believes that there is a change in memory management policy between gtkmm 2.2 and gtkmm 2.4. There isn't, and if there seems to be then it's a bug that I'd gladly fix. I've told him about 4 times now that there is no such change of policy, but he doesn't want to hear that answer. I've recommended valgrind to help with memory management issues. I think he calls it a change of "windowing" or something like that, though I'm not sure what that means. He refuses to create a test case to either debug his own code or to show a bug in gtkmm. This is silly and I object to the disinformation – if there is not a test case in bugzilla then it's not a proven bug, and I don't lie about what architectural changes I have made.

People need to create tests cases because library maintainers will not debug peoples' applications for them. Most people have no problem with that. I note also that I have a good record of fixing bugs shown by such test cases.

Go gossip

After so many people had recommended it to me, I finally got around to watching Black Cat, White Cat. It's wonderfully entertaining and imaginative, though I'm afraid many Romas probably find it highly offensive. For several days after watching it, I found myself doing little dances to the music. Now I want to watch all of Emir Kusturica's other films too.

I spent Friday and Saturday at LinuxTag in Karlsruhe, helping out a little at the GNOME stand. LinuxTag is much better than I expected. Somehow I always thought it would be just an expo, with a bunch of boring corporate stands. But there’s a great sense of activity and community, and there’s heaps of high-quality talks all day, every day. I’ll be at the next one. By the time I left, I had almost completely lost my voice, and I’m still mostly mute.

However, the people there are quite a bit more geeky than at GUADEC. Nobody at GUADEC would ask Michael Meeks about easy ways to build GNOME on LFS without hearing “I want it to be difficult. How can you make that easier?”. There were also very many SUSE users who had never even seen a GNOME desktop before, which explained their misconceptions.

It was great to meet lots of the German GNOME community for the first time, such as Sven Herzberg, Matthias Warkus, and the GPE developers. And it’s always good to meet Daniel Elstner and Frank Rehberger again. Michael Meeks asked everyone to hack on Mono, including me – I don’t think he knows who I am.

I am disappointed. Fedora has a sane time-based release schedule, but does not seem any closer to allowing community involvement. Debian has great community involvement but seems even further away from having a time-based release schedule, or even a release. Allowing either of these problems to go unfixed means eventual demise for a mass-market consumer distro.

Red Hat's merger with the fedora.us packaging community to make the Fedora distro seems to have actually made things worse. Before the merger, we saw the start of a single authorative community-based source for 3rd party packages, allowing people to actually install software that is not on the Red Hat disks. There needs to be one and only one source of such RPMs, or everthing forks at the first commonly-used 3rd-party library RPM, and quality control becomes impossible. But now fedora.us is no longer that community, because Fedora say that they are that community, except they are not. If Fedora don't fix it soon then they need to publically endorse fedora.us again so they can get the job done.

Most debian users use either testing or unstable, neither of which is suitable for regular users, and which are actually too fragile for most advanced users. The stable distribution is so old (GNOME 1.4) that it is also useless to regular users. There is no scheduled date for a new debian stable release, and no rush to make it happen according to any concept of feature/quality completion, because there is no scheduled date. Debian is a perfect example of how "soon" turns into "almost never". "soon" is never as good as an actual schedule.