libgda’s SqlBuilder API

SQL is complicated and strange and subtly different depending on the server, particularly for complex queries, which means anything that a user might find useful.

Glom built SQL queries internally, concatenating strings together with some helper functions. But that was still fragile and repetitive so I recently ported Glom to use the new GdaSqlBuilder API, via its Gda::SqlBuilder C++ wrapper. I don’t know of any similar open-source API for this in C or C++.

GdaSqlBuilder doesn’t completely hide the almost-free-form structure of SQL, but it does encourage you to only write queries that makes sense. As a bonus, you don’t have to worry about correct quoting, correctly representing values as text, correctly escaping that text, or correctly quoting table and field names. It should also hide most server-specific syntax, making it easier to port applications to different database servers. I’m happy to remove some of that awkward code from Glom.

Vivien Malerba was very responsive to my feedback, so I now think that the GdaSqlBuilder API is about as good as it can be in C. I think Gda::SqlBuilder is even nicer, thanks to C++ method overloading.

But it still doesn’t feel quite right – you can’t guess what the functions do without reading the documentation, many functions have similar names, and some functions can only be used on certain types of queries at certain times. I guess the Select and non-Select queries should be in separate (related) classes, instead of just mentioning “select” in the method name, but that would lead to annoying casting in C. Maybe I’ll do that in the C++ API.

Glom: Choice drop-downs can show related fields

I have spent the past month or so implementing a new Glom feature. It took much longer than expected, involving several large code refactors, and this feature was itself shown to be necessary by previously implementing another difficult feature. But I kept going because the feature seems genuinely and generically useful, if only to a few people. And I knew I was improving that code, reducing code duplication and simplifying it by making code generic and separate.

Anyway, the feature: Glom can show a drop-down (combo box) of choices when the user should enter a field value. This can be a hard-coded list, like “Mr, Mrs, Ms”, or it can be a list of values from a related record. For instance, it can be a list of person names from a contacts field, so you can choose a contact ID. Previously it could only show a value from the immediately-related table.

But you can now do more, because choices now uses the same item layout system as the regular list layout. So, for instance, if you are choosing an Actor’s Agent’s ID, as in this screenshot, you show not only the Agent’s name (as before) -  You can also show the Agent’s company name (Actors->Agents->Companies), from the doubly-related table. And you can even show the Company’s CEO’s name (Actors->Agents->Companies->CEO) from the triply-related table, if you need that for some non-contrived example. (In this example, I’m ignoring the fact that Actors and Agents and CEOs are in the same Contacts table, though reached via different relationships.)

This is without the Glom user writing any SQL, or having to understand the ugly SQL that’s necessary to do all that. I think that’s nice.

Also, because this uses the regular Glom layout system, you can now specify additional item formatting, such as different font styles (bold in this example), colors, or numeric formatting (such as numbers of decimal points or currencies). You’ll probably be happy with the default formatting that you’ve chosen for those fields though.

While implementing this feature, I also found that GtkComboBox needs:

  • To allow the menu to be wider than the GtkCombobox. For the screenshot, I’m using Tristan’s patch for that.
  • To allow “columns” to be aligned vertically. This isn’t really possible in GtkComboBox now because you can only add GtkCellRenderers to a single column instead of having multiple GtkTreeViewColumns as in a GtkTreeView. Tristan might make that possible, though it requires some other work first.

gtkmm 2.91.0

On Sunday I released gtkmm 2.91.0, following the recent GTK+ 2.91.0 release. This follows the removal of GtkObject, GdkPixmap, and GdkBitmap from GTK+. You’ll need to make some small, slightly-annoying, but generally good changes. For instance, the change from on_expose_event to on_draw() is awkward but obviously a far nicer way to do custom widget drawing, as if someone had actually thought about that API. Thanks Benjamin Otte.

Surprisingly, gtkmm applications, such as Glom, seem to work OK after porting.

Note that, despite the .0 version number, these aren’t the first unstable GTK+ and gtkmm 3 releases. The previous ones were called 2.90.x, but that looked too much like a stable release.

gtkmm 2.22

Yesterday I released gtkmm 2.22.0, the first API/ABI-stable version of gtkmm 2.22, wrapping GTK+ 2.22. It adds some new API and deprecates some old API. There’s nothing particularly useful, but this will help people prepare for gtkmm 3. As ever, gtkmm coders don’t need to wait for us to update gtkmm when there is new GTK+ API.

Nevertheless, maintaining two active gtkmm branches has been a huge and thankless drain on my time for the last few months. It’s still really hard to keep gtkmm 3 in sync with GTK+ 3, but I’m glad that I don’t need to keep my head divided between two versions of the API. More about gtkmm 3 later.

cluttermm releases and cluttermm_tutorial fixes

I have neglected cluttermm recently (a C++ API for Clutter). But Chris Kühl has recently fixed several cluttermm problems shown by example code in the cluttermm version of our tutorial and updated the tutorial itself. I’ve also added new API to wrap the new ClutterAction, ClutterActorMeta and ClutterEffects stuff in clutter 1.3/1.4. I’ve done new tarball releases to get the fixes out into the world. So I think it’s looking fairly healthy again, though I hesitate to call it stable before more people are using it.

The cluttermm API documentation is another good starting point.

Massifg Prints Valgrind Massif Graphs

Jon Nordby’s massifg is now usable and packaged for Ubuntu (in the Openismus PPA) and Fedora. The only slightly awkward dependency is libgoffice (for graph drawing), but that is widely packaged on distros.

It shows both the simple and detailed graphs of valgrind’s massif output, much like the old-style ms_print script. It can print the memory usage graph (also to PDF) and save it as a PNG file, so you can talk to other people about the results.

It’s far better than my previous attempts to modify the original ms_print perl script. There is still a bug (maybe needing a fix in libgoffice) that makes the detailed graph very narrow when showing the legend on small screens, but we are working on that.

Expecting a Daughter

Sigi is now in her fifth month of our second pregnancy. During our last scan we learned that it will be a sister for Liam. He’s already looking forward to her arrival. We feel lucky that we will have both a boy and a girl.

Her due date is almost exactly the same as last time – at the start of January. I’ll then be generally unavailable to the world for a few weeks, gradually reappearing as our routine settles down.

Trainee Mini Projects

We asked our 3 trainees to do some little projects to make sure that we ironed out any problems in their C knowledge before moving on to C++, to get them familiar with autotools, and generally to have code to talk to each other about.  I forced them to make actual tarball releases, so they can also complete features as if there were real users, instead of just hacking without focus. These are the modest results. Click on the links to see the descriptions and screenshots on their blogs.

Jon Nordby’s massifg: To show graphs from valgrind massif output. So far it only shows the simple graphs, though using the Cairo drawing API makes printing to PDF easy, so it’s already useful. I want Jon to do the detailed graphs too, but I’ve asked him to look for a proper Graph API first, because it’s tedious to do it all with just Cairo. Hopefully without acquiring awkward dependencies. He’d welcome advice.

Chris Kühl’s GMemory: One of those games that lets you turn over tiles for a moment and try to find matching tiles. It uses clutter and could probably be a candidate for the gnome-games package soon.

Patricia Santana Cruz’s GHangTux: A hangman word-guess game in which Tux the penguin loses his accessories rather than his life.

(The Gs in the names were their idea.)

I think they have all learned lots from the exercise and are ready for the next stage.

Openismus at GUADEC 2010

Tomorrow (Tuesday) I fly to Amsterdam and take the train to Den Haag for GUADEC 2010, joining 9 other Openismus employees: Karsten Bräckelman, Jens Georg, Ekaterina Gerasimova, Michael Hasselmann, David King, Andre Klapper, Chris Kühl, Jon Nordby and Patricia Santana Cruz. For Chris, Jon and Patricia, it’s their first GUADEC, so they are eager to soak up knowledge and will particularly enjoy meeting everyone.

This time Openismus is even sponsoring GUADEC to show our support, though at the lowest level because it’s already expensive enough to send 10 employees.

The T-Shirts are attractive and different again. Photos soon.