Tag Archives: Glom

www.glom.org

Glom: Storing PDFs

Glom already had an Image field type, letting you store pictures in the database and view them. It used GtkImage.

It can now store and preview PDFs, or anything else supported by Evince, via its evince-view library.

The contents can also now be opened in the external application via the context menu, and an Open With menu item even offers a choice of suitable applications via GtkAppChooserDialog. That’s why I haven’t bothered to add page navigation or zooming for PDFs in Glom itself.

It can even store arbitrary file contents, though it will just show a standard icon in that case. As a hack, it saves the contents as a temporary file in order to use GFileInfo to get the standard file icon. I haven’t managed to get the thumbnail via the G_FILE_ATTRIBUTE_THUMBNAIL_PATH attribute, but it’s probably not reasonable to expect to get that thumbnail for a completely new file.

In fact, I use the same temporary file hack to get the PDF data into the Evince EvView. I must figure out how to make EvView render from data in memory instead of a filepath.

It would be nice to show a simple video player for video files, but I haven’t found a suitable gstreamer-based library for that yet, though I guess I could copy/paste some code. And anyway, it doesn’t like huge files right now.

I use glib’s mime-type sniffing function to guess the mime-type, to decide how to display or open the document. This works surprisingly well but we really need to store the original mime type, and probably the file name, in extra database fields.

Update: I’ve given up on getting a thumbnail, so I’m just using g_content_type_get_icon(), which avoids the need to save a temporary file to disk. And for EvView, I’ll try to add API to allow loading from memory.

Glom: Simplified main window

As planned, I have made the main Glom window even simpler. I’ve moved the table title down next to the “notebook” tabs, moved the records count up to the top. I’ve  hidden the “mode” concept because it’s now just a matter of whether you are entering find criteria or not. I’ve also removed the User Level menu, moving it’s toggle menu items to the top of the Developer menu, and I removed the User Level label, hoping that people don’t need that clue.

Before: Glom 1.18:

After: Glom 1.19/20:

(There are other differences between GTK+ 2, used by Glom 1.18, and GTK+ 3, used by Glom 1.19/20, and theme differences.)

Notice also that by using the custom-notebook widget, instead of GtkNotebook, the window does not need to be as wide as the widest notebook page even when that page is not actually showing.

This is in git master. I’ll do a new release when the dependencies get the tarball releases that I need. It will also fix the Find feature, which seems to have been broken in various ways since Glom 1.16.

Glom: GtkNotebook with no frame

GtkNotebook has a frame around the page that it shows, grouping that page’s widgets together. That makes sense when the notebook is part of a more complicated UI. But Glom uses a GtkNotebook for almost all of its main window, taking up all of the window’s width. The frame needs an inner border that wastes space and the nesting actually makes the UI look more complicated than it is.

That frame is not optional in GtkNotebook, so I had to create a custom Gtk::Notebook-like class to replace it in my code. The result is mostly better, though I don’t like those two toggle buttons much. Suggestions are welcome.

I will also move those top labels around, putting them in the same row as the List and Details toggle buttons, but this is a start.

gtkmm 2.24 soon

I will soon release gtkmm 2.24.0. This one should really be the last release of the gtkmm-2.4 API, give or take some minor bug-fixes. Afterwards, we can focus completely on gtkmm 3.

So this is your last chance to mention problems that we should fix in the gtkmm-2.4 API. Remember that it’s just meant to help you prepare for porting to gtkmm 3 so we’ve added as much of the new API as possible to gtkmm-2.4, but tell us if we missed something.

I already have gtkmm-documentation and glom building in branches with gtkmm 2.23/24 with no use of deprecated API.

Trainee mini gtkmm projects

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 contributions to GTK+

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.

  • 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.

gtkmm 2.91.2

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.

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.