I’ve got to know goocanvas (API documentation, browse CVS) better over the last week. I achieved what I needed, but it could have been easier.

No generic positioning of items

You can’t set the position of goocanvas items. Well, you can set the x,y position of a GooCanvasRect, and you can set the points in a GooCanvasPolyline, but there is no generic position API in the base GooCanvasItem interface.

This makes it very difficult to write generic code for dragging, loading, and saving. All the items could support a generic API – it wouldn’t matter if the x,y is some arbitrary point in the item. I have implemented this in derived classes in C++, with some multiple inheritance awkwardness, but life would be far easier if it was in the GooCanvasItem base class itself. Erik Osheim did this in Python too. You wouldn’t want to do it in C. It seems to be a regression compared to libgnomecanvas, which has gnome_canvas_item_move().

Note that you can “translate” generic GooCanvasItem items, but

• Two APIs for the same thing, to be used at different times, is annoying.
• You can’t easily discover the actual position after translating. For instance, the GooCanvasRect x,y properties are not changed by goo_canvas_item_translate(). That function just changes a translation matrix which is applied to the x,y, rather than changing x,y.

I guess this is the cairo drawing system, but the canvas API shouldn’t force that on me. This is a major problem in the API for me, so I hope I can persuade Damon to let us add this.

Update: We created a GooCanvas generic positioning patch for this.

No high-level funtionality

You have to implement too much yourself. Not every application needs the ability to drag and resize items, but many do, and it would be nice if this was easy and consistent. I implemented drag-to-move, snap to grid, snap to rules, ctrl-to-restrict-drag-to-one-axis, resizing via corners and edges with appropriate arrow cursors, and signalling for a context menu on right-click. I still need to do selection highlighting and moving of multiple selections. I did that with a CanvasGroupResizable class that can take a child to be manipulated, though it currently only works with a rectangle child. It uses the generically-movable rectangles and lines that I mentioned above.

The next person to reimplement this will probably make it behave subtly differently.

Now that I finally have a canvas with the basic functionality that I need, I was able to reimplement and improve Glom’s Relationships Overview. I’ll now start using it to implement print layouts showing field data.

Printing is easy

goo_canvas_render() makes printing really easy with GtkPrintOperation.

Minor issues

• Instead of having a GooCanvasContainer type, there’s a goo_canvas_item_is_container() function that tells you whether goo_canvas_item_get_child() and friends are useful.
  Damon seems to like the idea of correcting this. Update: We created a GooCanvas Container-type patch for this.
• The root item idea doesn’t seem useful. You always have to use goo_canvas_get_root_item() to actually add or remove items to the canvas. I’d like to make the GooCanvas widget implement the GooCanvasContainer interface instead.
• The model/view separation doesn’t seem useful, though I might be persuaded by a real life example. I don’t see a big need to display the same canvas twice in the same UI. In GtkTreeView the model/view separation allows you to show two views with differently sorted or filtered models, but I don’t see an equivalent in goocanvas. I can imagine using different zoom levels or different visibility (at different zooms) levels, but I don’t see a way to specify that for a canvas “view”.
• The *_new() functions need to be fixed to just use g_object_new(), for language bindings. Bug filed.
• The *_new() functions, such as goo_canvas_rect_new() correctly return an initial reference if you pass NULL for the parent parameter, but do not return a reference if you specify a parent. That’s maybe convenient if you can remember, but its’ an invitation to make mistakes.

At first glance, libccc has many of the same problems. Note that I was dissuaded from trying libccc first because it was started after goocanvas, without any stated reason, and due to the lack of documentation on the functions that I looked at.

I should look at HippoCanvas too.

As mentioned before, Glom needs a more precise way to specify print layouts, for instance to print on a pre-printed form. I’m looking at the problem again. At the same time, Johannes is working on a prettier drag-and-drop UI for Glom’s regular (automatic) view layouts.

For now, I think I’ll start with text areas that don’t move or shrink depending on their content. But for later I would like to gather some examples of how other software does this. I wasn’t impressed with what I found, though FileMaker is the best of the bunch:

FileMaker print layouts

FileMaker offers two ways to achieve this: You can use the <<fieldname>> placeholder format in static text, or you can specify that a field’s text box will be moved left, right, up or down until it hits another box. Both techniques can be seen in this screenshot:

Kexi print layouts

Kexi (version 1.1.3) doesn’t seem to have any support for printing, but please correct me if I’m wrong. (Update: It doesn’t support printing of details forms – the print menu is grayed out in that case. It does support printing of list views, though the result is arranged differently than what’s on screen. It has a reports feature, available under “queries”. For me, a report is for multiple records, not a single record, and I’d like to keep them separate to keep things simple.) However, the regular layout is pixel-perfect rather than automatic, which would be suitable for precise printing, though awful for all other situations.

Knoda print layouts

Knoda (version 0.8.3) seems to support printing, but I didn’t find any features to support flowing of variable sized text. Its layout is pixel-perfect rather than automatic, as with Knoda and Access.

Microsoft Access

It looks like Access (the version in Office 2007) also doesn’t have special printing support. I think you are just meant to design a regular custom form and print it. But I couldn’t find a way to print an invoice in their “Northwind” example, so I’m guessing. The regular layout is pixel-perfect, with the ability to make widgets stretch to fill available screen space, with the new “Anchoring” feature in Access 2007.

As seen in this screenshot they also use an invented markup (or mini programming language) to show data, as in FileMaker, but it’s even more complicated here.

libgda reports

libgda has some reports support (example). It uses custom XML tags (and a custom mini programming language for conditionals) to replace XML nodes (arbitrarily named, without any libgda prefix, it seems, such as <row>) with query results in, for instance, DocBook. So that’s not really useful for the precise layout problem and seems targeted more at multiple rows reports rather than single record printouts. Glom already has its reports feature which seems equivalent, though it is more integrated with Glom concepts such as Relationships and Related Fields.

Others?

What other systems should I look at? Note that I’m not interested in anything that requires the user to edit XML or SQL queries, though it’s possible that I could reuse some of that implementation some day.
By the way, having to use all these other systems for a while convinced me once again how badly Glom is needed. They are so unnecessarily low level and complicated, instead of directly helping people to achieve their actual goals.

I finally had a chance to test out Vivien Malerba’s cursor support in libgda, and fixed some problems. It lets you use the “ITER_MODEL_ONLY” parameter to get a GdaDataModel that should be used only via a GdaDataModelIter iterator. That uses the SQL “FETCH” command to get chunks of rows at a time instead of getting all the rows even if you are only interested in a few of them. I added an example of this to libgdamm.

For instance, Glom won’t cause libgda to get all one million records to show you a list of all records if the GtkTreeView only has space to show ten at a time. However, I’m not sure if it will get all the intermediate data when someone moves the scrollbar quickly from row 1 to row 500,000, because of this comment in the PostgreSQL documentation for FETCH. I’d like to avoid hacking on Postgres to fix that.

"ABSOLUTE fetches are not any faster than navigating to the desired row with a relative move: the underlying implementation must traverse all the intermediate rows anyway.”

So far this is only implemented for libgda’s PostgreSQL provider. It would be great if people could implement it for the other providers. The “FETCH” command seems to be fairly standard SQL, so it should be easy.