I just released Glom 1.12, roughly in-sync with GNOME’s release schedule.

Most noticeably, Glom databases no longer require a user/password to open them, at least for the default self-hosted databases. That should be much less annoying. You’ll only need to specify a user and password when you choose to share your database over the network with other Glom users.

We’ve also cleaned up libglom a bit, and David King has shown that it can be used for a simple Qt-based Glom viewer, provisionally called qlom.

I’m currently working on a Maemo 5 (Fremantle) branch of Glom, with a radically simpler UI with picker buttons and more sub-windows. I need to get that mostly done so I have something for my Handheld Glom talk at the Maemo summit in Amsterdam. I’m planning some rants for that talk – I think it will be entertaining.

I love how full-on Nokia has launched the new N900 handset. We work so much on the underlying technology that it’s a welcome reminder how users feel emotionally about the whole product. The enthusiastic response is real encouragement for our developers. But don’t be confused by Nokia’s odd emphasis on “mobile computing” in their text – this is a highly capable smartphone that’s about communication and lifestyle rather than mere computing for the sake of it. This is their latest greatest phone – the one that people will hunger for.

For a year or so we’ve had to keep the secret that Nokia want to make phones with Linux, though every other major handset company was already doing it, because it make so much more sense than fighting the eccentricities of all those in-house proprietary platforms. I’m glad we can talk about it now, though we have vague orders to not to go into too much detail until Nokia World 2009 next week.

This product has been the major part of our work at Openismus, and is the reason for our growth, keeping Mathias, Jan Arne, Daniel B, Karsten, and André very busy and determined, with the others helping and learning so we can build on our success. Soon the code will be in our hands.

People often complain that autotools is complicated. But the alternatives generally involve a learning curve, require large changes to existing projects, and don’t provide the features or the command-line interface that we’ve become used to with autotools, making life difficult for people building tarballs, and for distros’ packaging tools.

One of the biggest annoyances with traditional autotools has been the need for a Makefile.am file in each sub-directory, and the need to create (and link) non-installed convenience libraries in each one. That leads to lots of repetitive Makefile.am code. More code means more errors, less clarity, and difficult refactoring. I had forgotten how much I hated that about autotools when I first learned it.

One of the advantages often mentioned for alternatives such as cmake is the ability to define the build in just one text file. However, automake has supported the non-recursive way for a while. Now you can have just one top-level Makefile.am. The configure.ac is still separate, but that’s fine with me.

Daniel Elstner changed Glom to use a single Makefile.am, removing 47 annoying little Makefile.am files while preserving our special stuff for client-only, Maemo, and Windows builds, with no disruption for developers using the source from git or for people building from the tarball. It’s a great improvement that shows how attractive non-recursive automake can be. OK, so Daniel is an autotools expert, but I’d still rather move from autotools to non-recursive autotools than take the leap of faith needed to move from autotools to something completely different.

Apparently this is also more efficient, leading to faster build times, particularly when building in parallel with the -j option, with more correct dependencies. And there’s no need to mention those convenience libraries repeatedly to work around linker errors.

Together with autoreconf (replacing hand-built autogen.sh files), autotools can be much nicer these days.

Going Home

I’ve spent the weekend at GUADEC in Gran Canaria but I fly back today to be at home for wee Liam who I really miss. I’ve noticed that people didn’t really understand that for the past year and a half I’ve spent half the week taking care of him, and the rest of the week running the company and doing just a little coding. We should have a place in a crèche in our street starting in October so things will eventually get back to normal.

In the meantime it’s been great to see old friends but I can’t talk about doing much public work in GNOME recently, or promise to help with things.

Maemo and Qt

It’s a relief that Nokia finally announced, via Quim, that they will use Qt instead of GTK+ in future versions of Maemo, though the next version, Fremantle (Maemo 5) is still entirely GTK+. Openismus have known about this for some time and have been preparing for it, but we couldn’t talk about it. As enthusiastic C++ developers, this is less disappointing to us than to other GNOME companies, and it’s been great to see Qt’s development gradually open up to the outside world.

However, it’s clearly a rather arbitrary and disruptive decision. I suspect that some managers are dictating the Nokia-wide use of Qt even in projects that don’t otherwise share code, without understanding the difficulty of the change. UI code is never just a thin layer that can be replaced easily, even if it looks like just another block in the architecture diagram. Likewise, hundreds of C coders cannot become capable C++ coders overnight. I expect great difficulties and delays as a result of the rewrites, but Openismus will be there to help.

Openismus T-Shirts

The economy has affected the traditional GUADEC T-shirt supply, making the Openismus T-shirts even more desirable. Introduce yourself to David King if you’d like one of the last ones from his backpack before he leaves on Tuesday. André, Karsten, and Johannes are here too.

This cross-desktop conference is ideal for David because he’s been intensely learning about all of GTK+, gtkmm, and Qt in the past few months.

As per tradition, the new Openismus T-Shirts are ready for GUADEC 2009 (GCDS). They are again unlike last year’s, and simple enough to wear among civilians. We were a little rushed this year but they turned out nice. Thanks to Kat for fixing things in Inkscape and getting them done.

We only printed a limited number, so seek out an Openismus developer over the first weekend to get yours.

Now that we’ve found a place to get these done in Berlin we’ll probably do a new design (2009 1/2) for the Maemo Summit in Amsterdam in October.

We have cleaned up the maemomm API reference and put the result online. Here’s an example for the Hildon::TouchSelector widget. Pages such as that are linked often from the “Programming with maemomm” book.

Like the gtkmm API reference, the maemomm API reference is partly autogenerated from the C API reference, with some clever automatic changes, and some manual overrides, so it will improve as the hildon C API reference documentation improves.

Thanks, David. Yes, me moved it to trunk/

The example code link is 404
Maybe: https://garage.maemo.org/svn/maemoexamples/trunk/example_desktop_widget/

This post is a general ramble about the limits of keeping API the same on significantly different platforms. It uses Maemo’s Hildon and Maemo’s Qt as examples, but don’t get offended. Hildon’s new UI in Maemo 5 is wonderfully appropriate for small touch-screen devices, and the API is the best that the developers could do in the short time available, in their circumstances.  Not much can be changed in Hildon now anyway until a theoretical Maemo 6. And Maemo’s Qt is only just getting started.

David King blogged that we have draft documentation online for the Maemomm (C++) API for Maemo 5.

The text needs to be filled out a little and corrected here and there. But we have figured out how to actually use the new widgets, as shown by our example code. And the list of screenshots of the examples is probably the first time you’ll see most of the new Hildon widgets all together. It’s radically different to the previous Maemo UI, rightly so.