I recently got a Kindle 3 which I’m really enjoying.
As an experiment, I published a Kindle version of the “Programming with gtkmm” book. I don’t actually expect to sell many, though it could be a convenience for some people. I wish I could just “Print to Kindle” from my computer.
I set the “list price” at $2.00, but it appears as $4.60 to me here in Germany. It might be $2.00 to people in the US. I get 70 cents each time for both.
The European GNOME Events Box is currently missing because UPS delivered it to a random address in Odivelas, Portugal instead of the correct address in Sevilla, Spain, and they can’t get it back.
We are usually happy with UPS but they’ve just thrown up their hands and given us a claim form, asking us for the receipts for all the items in the box, some of which were gifts from GNOME-friendly companies.
I don’t have much confidence that UPS have really looked for the box. So if you are near Odivelas, it would be great if you could politely ask there. Please ask me for the full address via email – it doesn’t seem fair to publish it.
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:
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+:
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.
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.
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:
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.
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.
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.