Gtk Canvas

This page tries to collect highlights and drawbacks for the most known canvases around, plus some other information that hopefully will be useful to determine a sensible feature set and the best candidates to fill the canvas gap in GTK+.

Candidates for a new GtkCanvas are marked with a colored row. Other canvases are just for comparison.

Use Cases

• Interactive diagrams
  • plots
  • UML editor, entity-relationship, ...
  • Desktop publishing app
  • Multi-track audio editor
  • Air traffic controller simulator.
  • Database relationship viewer.
  • PIM Synchronizer connection viewer.
  • ...
• Possibly several views on the same data
• Printing

• Creating fancier UIs for apps, possibly with embedded widgets (control-center shell, MugShot, something like GMail, ...)

• Animations and games
• show and manipulate pre-drawn graphical content (i.e. load from a .svg, get objects by their name, ...)
• Having a concept of "scale" for zoomable UIs.

Some Links

GnomeCanvas

This is the existing (unloved) GNOME canvas, included here for reference. We should try to avoid regressions when choosing functionality for a new canvas.

• API Reference: http://developer.gnome.org/doc/API/2.0/libgnomecanvas/index.html

• Repository: http://svn.gnome.org/svn/libgnomecanvas/

libccc

A candidate for the new GtkCanvas.

• Project Page, Roadmap: http://live.gnome.org/Criawips/CriaCanvas/

• API Reference: http://kenny.imendio.com/~sven/apis/libccc

• Repository: http://gitweb.freedesktop.org/?p=users/herzi/ccc.git;a=summary

GooCanvas

A candidate for the new GtkCanvas.

• Project Page: http://live.gnome.org/GooCanvas

• API Reference: http://library.gnome.org/devel/goocanvas/0.9/

• TODO-List: http://svn.gnome.org/viewvc/goocanvas/trunk/TODO?view=markup

• Repository: http://svn.gnome.org/viewvc/goocanvas/trunk/

FooCanvas

• Repository: http://svn.gnome.org/svn/foocanvas/

Hippo-Canvas

• Project Page: http://developer.mugshot.org/wiki/Hippo_Canvas

• Tutorial: http://developer.mugshot.org/wiki/Hippo_Canvas_Intro

• Repository: http://svn.mugshot.org/svn/dumbhippo/trunk/client/canvas

GeoCanvas

• Project Page: http://sourceforge.net/projects/geocanvas/

• API Reference: http://geocanvas.sourceforge.net/crcanvas/api/index.html

• Repository: http://geocanvas.cvs.sourceforge.net/geocanvas/

• (Apparently uses foocanvas)

clutter

• Project Page: http://www.clutter-project.org/

• API Reference: http://www.clutter-project.org/docs/

• Repository: http://svn.o-hand.com/repos/clutter/

• TODO-List: http://svn.o-hand.com/view/clutter/trunk/clutter/TODO

Qt4 Graphics View Framework

• API Reference: http://doc.trolltech.com/4.2/graphicsview.html

Concepts

Notes

• Primary Layout model: How items are layed out on the canvas:

  • "scene graph": the entire scene is constructed free-form, with every component of the scene declaring its spatial and dimensional attributes; the whole scene is a graph (hence the name) where every node might have children and at least one parent (often just a single parent). Layout constraints are usually implemented inside containers. See Scene graph on Wikipedia.

    • Roughly like GtkFixed or SVG.

  • "boxed": the scene graph is constructed only following layout constraints, usually following a "box model". See Box modeling on Wikipedia.

    • Roughly like GtkBox, GtkTable, etc. or HTML/CSS.

• Infinite scrolling should be defined or removed; as far as I understand, it's the ability to wrap around the viewport, which is expected from a canvas displaying maps but it's not really a requirement. many canvases can implement this functionality right on top of their own API. EmmanueleBassi

  • It's the ability to scroll beyond the "core document", just like in gnumeric where you can scroll to the last row available in a spreadsheet and beyond that.

Basic Features

Notes

• Generic Positioning: Whether items can be positioned via a base class interface, instead of only via specific APIs for derived shape classes.
• Accessibility: Whether it uses ATK to provide information about the items.

• Printing Support: For instance, make it easy to render to a cairo context in a GtkPrintOperation.

• Item Grouping: TODO: This should be more clearly defined.
• Unit Support: Whether distances can be specified in real units rather than just pixels.

• Embedded GTK+ Widgets: Whether the canvas can show, for instance, a GtkEntry. Ideally, the widget would scale/rotate/etc just as other canvas items do when they are transformed.

• GTK+ CellRenderer: Whether the library offers a GtkCellRenderer objects that can render the canvas into a treeview cell.

• Pixel Alignment: Whether attempts are made to align items on display pixels for better appearance.

• Automatic Layout: What modes are used, when automatic layout is offered - that means any automatic layout (like GtkBox) rather than just exact positioning (like GtkFixed):

  • WxH: Width for Height
  • HxW: Height for Width
  • NaS: Natural Size
• Primitives: The basic items offered by the library.

Highlevel Features

Notes

• Built-in DnD support: Whether items can be moved on the canvas without needing to implement much code.
• Serialization: Whether the state of the items (including its children) can be saved (e.g. to a text markup) and reloaded later.

• Rapid Prototyping: Whether the GtkBuilder API (and glade in future) can be used to place items on the canvas. Probably related to Serialization.

• Inline text editing: Support for text editing without an embedded GTK+ widget. This provides better visual feed back, as you see what you get when editing.
• Non-scaled items: Whether items can be marked as not-for-scaling when the entire canvas (or maybe group) scales. For instance, graph axis names, place names on maps.

API Details

Notes

• Opaque Data Structures: Whether the C struct may be accessed directly, or if only functions should be used.
  • Doesn't seem unfixable, so it doesn't seem very relevant to the choice. murrayc.

    • It's unfixable without breaking API/ABI, so it should be done before integrating any code in GTK+. EmmanueleBassi

• Initial Object Ownership: C Convenience API to reduce repetitive code.

  • For instance, GtkWidget uses an initial floating reference, in combination with GtkContainer which sinks that initial reference.

  • Not relevant to most language bindings.

Metrics

• Lines of code regarding sloccount, without auxiliary code like test suites, examples or similar.

Comments

• Another thing to compare is performance: for instance, to how many canvas does each implementation scale? (a bench could be tring to draw 1000, 10000, 100000 etc simple rectangles, both with and without intersactions etc) - PaoloBorelli

  • I'm working on some benchmarks for - at least - goocanvas and libccc (as these seem to be the two candidates with maintainers who like to see a GTK+ inclusion) - SvenHerzberg

• "Items Grouping" should be more clearly defined, or split into sub-features. For instance, in goocanvas, child items use the transformation and style of their parent group. What does it mean for the other canvases? murrayc

  • the same happens for Clutter as well: the transformation matrix of a container actor is also applied to its children (or should be: it's not enforced, so you can override this behaviour). - EmmanueleBassi

    • sounds like the typical scene graph model - MathiasHasselmann

• A minimal code example (preferably in Python) that does the same thing for each canvas widget would be most interesting.

• Another important canvas system is provided by Gaphas http://gaphor.devjavu.com/wiki/Subprojects/Gaphas. Pure python, depends on Cairo only.

Any thoughts/comments? please write them here