In August I mentioned the mini GTK+ C projects that our trainees completed: massifg, gmemory and GHangTux.

They recently finished some mini gtkmm C++ projects too, because I think gtkmm is a comfortable way to learn good C++ habits after GTK+. Here they are:

• Chris Kühl’s Merkmal, a port of gmemory to gtkmm and cluttermm. It’s a card memory game.
• Patricia Santana Cruz’s GHangtuxmm: A port of GHangTux to gtkmm. It’s a hangman game.
• Jon Nordby’s glom-postgresql-setup, which does the awkward server configuration that typical Glom users don’t want to worry about.

They are now moving on to Qt and they’ll get some exercise on deeper OO and C++ concepts. In fact, Jon Nordy has already created a QImage plugin to support the OpenRaster image format.

Openismus has made several contributions to GTK+ recently, getting changes into the upstream releases, doing things properly via bugzilla and the mailing lists, working with other developers even when it’s complicated, so it’s done right. This has helped my application, Glom, which uses GTK+ via gtkmm. It shows that we could do the same for you.

For some of our employees this is also a slight reward for being so busy coding with Qt right now. We love GTK+ as much as ever, regardless of one big company’s arbitrary choice to stop using it. Some of us like it even more now.

A short list of recent Openismus work on GTK+:

• The GtkToolPalette widget
  Started by our Mathias Hasselmann, continued by our Jan Arne Petersen and finished by Johannes Schmid.
• The GtkScrollable interface
  Started by Jan Arne and recently finished by Tristan Van Berkom.
• Extended layout (height-for-width geometry management)
  Started by Mathias, finished (almost) by Tristan.
• GtkComboBox’s set_popup_fixed_width() function
  by Tristan.

Tristan also created a couple of useful container widgets that were not needed in GTK+ itself so they are now in libegg. They were made possible by the extended layout support in GTK+ 3.

• EggWrapBox
  By Tristan. This positions child widgets in sequence according to its orientation. For instance, with the horizontal orientation, the widgets will be arranged from left to right, starting a new row under the previous row when necessary, as in a toolbar or tool palette.

• EggSpreadTable (screenshots)
  By Tristan and ported back to libegg by our David King. This positions its children by distributing them as evenly as possible across a fixed number of rows or columns, like newspaper columns.

Just a day after the GTK+ 2.91.2 release, I managed to release gtkmm 2.91.2, with (hopefully) all the new API. I have Glom and the gtkmm-documentation examples building with the latest gtkmm as a test.

I also did a release of glibmm 2.27.1, matching the glib 2.27.1 release. José Alburquerque has been working very hard on this, while also working on gstreamermm. But we really need some feedback on all the new API, particularly the Gio::DBus* stuff. Someone needs to sit down and write example code to see if it even works. We skipped the stable glibmm 2.26.x releases because this had not happened so we were not ready to call the API/ABI stable.

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.