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.