Glom 1.0 is out. It’s reasonably stable, and it does many useful things, in a simple way:

• Define fields in tables: number, text, boolean, date, time, and image.
• Define relationships between tables.
• Define field calculations with python.
• Define field lookups.
• Define default field formatting which can be overriden later.
• List and details views, with automatic layout when resizing.
• Related records portals on the details view.
• Related Fields on list and details views.
• Dropdown lists of choices for field entry.
• Open and Find buttons next to ID fields (used by relationships).
• Find mode: Using the existing list and details layouts, with a built-in full text search.
• Reports: Simple reports with group-by and summary parts.
• Per-table user/groups access rights.
• Scripting: Add a button to the details view to run a python script.
• Internationalization: Translate titles of tables, fields, layout items, relationships, reports, etc.

All without SQL. This is enough for regular people to create usable database systems, though the current version would probably be challenged by tables that have millions of records.

Glom will now voluntarily follow the GNOME release schedule, so new features will be implemented and stabilized every six months. I’m looking forward to implementing all the new features, but I will take a break to do some paying work. I recommend Ubuntu Dapper for trying out Glom – wait for the Ubuntu release on April 20th June 1st 2006 if you want a stable system.

Many thanks to the beta testers who helped me to reproduce and fix some annoying bugs, particularly Peter Williams, Ryan Paul, Phill Gillespie, Halászvári Gábor, and Daniel Holbach.

I know I declared a Glom beta, so the features should be frozen, but I just couldn’t help it. I’m working on a Film Production management system, to put Glom through its paces, and hopefully to sell. I needed these new features:

• Multiple levels of sorting on reports.
• Vertical report groups: Rows of field values inside record rows, to show more information on a row.
• Notebook tabs, to put more information on the details layout. This was a much requested feature in FileMaker for the last ten years, requiring awful unmaintainable hacks to simulate it, which they even used in their example files. I notice that they are making a big deal about finally adding it in their marketing for the new FileMaker version.
• Doubly-related fields. For instance, to put Actor(via Characters::actor_id)::Agent(via Actors::agent_id)::name on a Character’s details. In FileMaker you have to create a calculated field in the Actor table, which evaluates to Agent::name, and then show that calculated field on the Character details. This way is a lot simpler, so you don’t need to understand what I just explained.

I’ve been squashing lots of bugs, as ever, and I think Glom is nearly 1.0 material, so I’m calling 0.9.8 “Beta 1” and hoping that it gets some more testing. Realistically, only people using Ubuntu Dapper will be able to test it easily, thanks to Daniel Holbach.

There’s lots of post-1.0 features that need to be done, and it’s easy to start convincing myself that they are essential, but it’s also important to get some set of functionality into a stable usable form. And the reality is that the Glom 1.0 features are actually quite substantial. There’s nothing even remotely like this in free/open-source software or Linux at the moment, and it’s a deal-breaker for a significant group of users.

For now, It still lacks some features that (closed-source, non-Linux) FileMaker Pro has, but it also make several things easier and has that Postgres magic to win over hardcore sysadmins. So, if FileMaker ever get around to doing a Linux port, Glom would probably still be a winner.

Just to get this far has been an immense amount of work for me. I’ve taken months off paying-work about 3 times now to push it along, risking financial collapse each time. I actually started it five years ago, but development accelerated when I decided not to waste time making it impossibly generic and über-adaptable. To get an idea of how important this has been to me: This is the reason that I started working on gtkmm, libsigc++, bakery, libxml++, libgnome*mm, and libgdamm (taking over maintainership in some cases, starting them in others), because I just couldn’t imagine producing a full-featured app without (real) C++, because that’s what I do. Yes, gtkmm is, in a way, just a side-effect of Glom for me. You’ve got to get obsessed and stay obsessed.

At some time I’ll have to implement a type of printout or report in Glom that uses fixed positioning. For instance, to enter text into the correct spaces on pre-printed forms, or just so that printouts always look the same. At the moment, printouts take up as much space as necessary, and flow appropriately (I “print out” to HTML in the browser at the moment).

So, suggestions are welcome for some code that I should reuse, or adapt. I guess it would need the following abilities.

• Specify text areas precisely, such as specifying the position and size.
• Optionally specify the position in terms of alignment, so that text areas slide left or right.
• Flowing text into those areas, and simply truncating the text if it’s too big. (Or maybe making the font size smaller.)
• Text justification inside the text areas.
• Specifying page margins.
• Coping with a changing page size (e.g. A4 versus Letter) by increasing/cutting-off margins.
• Have a nice GTK+-based UI for doing this.

Something using cairo and pango would be nice.

Extending Glom via python is such a marketable feature that I spent a couple of days to add a button layout item so it’ll be in version 1.0. Glom already supports calculation of field values with python, but this allows arbitrary actions when the user clicks the buttons, equivalent to FileMaker’s “scripts”. The example has a slightly-modified pygtk helloworld program in the button.

The python script already has access to the record details. In future we could add API so that python code can, for instance, add records, navigate to tables and records, find, and print.

Boring technical bit

It’s been a hard week. I’ve been doing some major (more repetitive than conceptual) refactoring of the Glom source code, to make it use smartpointers for lots of the information, instead of copying by values lots. Copying by value gave me stability when I wasn’t sure how things should work, but now I’m more sure about where things should be explicitly created, shared, or copied. The memory management feels a bit like Java, but at least I still have the const keyword, and at least I still have strong compile-time typing. I’d be lost without them.

Exciting new feature

The point of this was to support translations of everything in Glom that can have a human-visible title instead of just an identifying name, such as tables, fields, reports, layout parts, relationships, etc. Rather than have little translation buttons next to each title, I chose to pull it all into one list. And if you develop a system in French but then later have to deploy it in Germany, that should be OK too. You can even test it without changing your locale, though you’d have, for instance, German field titles with Spanish menus and buttons.

It would be very easy for someone to implement Import and Export to/from regular gettext .po files. Maybe I can even check them into cvs so that the wonderful GNOME translation teams translate the example Glom system for me.

I had considered this a post-1.0 feature, in Glom’s list of planned features, but I realise that I need this for clients in Germany, so I can still use English as my first development language when creating Glom solutions. As usual, don’t forget that your company may fund me to implement the remaining features.

Unfortunately, it only uses the first part of locale names at the moment, such as “de” for “de_DE.UTF-8”, so, for instance, you must use the same German translation for Germany, Austria, and Switzerland. That’s because I can’t find any list of real locales (whose names should also be translated themselves). iso-files seems to have only language names instead of locales.

I’ve put lots of work into Glom over the last few days. There are a couple of nice new features, needed for (my idea of) version 1.0 completeness. I guess this will be available in Ubuntu (maybe only Dapper) real quick, thanks to Daniel Holbach. It is a little difficult to get all the dependencies when building it yourself.

Found Set

As in FileMaker, you are always looking at either all the records or a set of records based on a Find that you just did. Now there’s visual feedback about this at the bottom-right of the window, and a button to get back to seeing all records.

Quick Find

Whenever I built systems with FileMaker I would always create a big concatenated calculated field for doing quick full-text searches, and I’d make this show up on the Find screens. Glom just gives you this feature for free. There are probably more efficient ways of phrasing the SQL, but that can be improved behind the scenes.

Examples

The glom example now contains example data, including an attractive picture of me in a record in the Contacts table, some made-up products, and some invoices that use them. And now you don’t need to be aware any more of the name of the database on the postgres server. Glom automatically chooses a new database name and associates the new file (created from the example, like a template file.) with the database.

Glom now has an Image field type, for pictures. It's simple and it works.