canvas notes

[Havoc Pennington <hp redhat com>]

Hi,

Been thinking about canvas widgets a little this weekend, thought I'd
write down some notes. Some people are doubtless way ahead of me.

This isn't very organized. Summary of this mail is that GnomeCanvas was
missing some very useful features a canvas can have, so I was
underestimating the value of a canvas widget.

Among other things I've been looking at scene graph APIs, specifically
Piccolo (a 2D scene graph using Java2D):
http://www.cs.umd.edu/hcil/piccolo/
and Java3D:
http://java.sun.com/products/java-media/3D/

Piccolo is BSD-license. Java3D be careful with since it has a
noncommercial use license, I avoided looking at source code or Sun 
specs.

There's Avalon also I suppose but I haven't read recent things about it.

I see Piccolo was cited here:
http://mail.gnome.org/archives/gtk-devel-list/2005-February/msg00071.html

So random thoughts.

1. 2D vs. 3D (Cairo vs. GL) seems like a tricky question
   that we also face on the compositing manager level.
   Do we want two entirely different scene graph APIs
   for this? Or one grand unified scheme where you can 
   put Cairo-on-Glitz into flat portions of the 3D graph?

   Possibility: a hybrid approach which is an OpenGL scene
   but designed for a mostly-2D desktop UI. i.e. a not-very-rich 3D 
   API, and convenience weighted toward 2D. Not sure what this
   means.

2. Animations. Scene graph APIs make it simple to say 
   "this object should move back and forth" or whatever. They have 
   built-in stock animations such as animated affine transforms
   (translation, shrinking, etc.) Very useful for smoother 
   and snazzier UIs.

3. Behaviors. It should be trivial to implement "object is 
   draggable by mouse" for example without writing your 
   own event handler.

4. Widget embedding. Absolutely critical to using the canvas
   for real-world UI. The widget embedding can't be broken 
   as in GnomeCanvas or it isn't useful; layering and events must work 
   properly. Affine transforms probably should work properly, and 
   when you think about animations (minimization, etc.) could even be 
   useful.

5. Multiple views. Sometimes useful, needs to be designed-in. 
   Should probably be item-by-item rather than for an entire
   tree of items...

   Multiple views means that you can have 1-1 mapping from 
   application data objects to canvas nodes.

6. Path item. In C at least it's easier to do this:
     path = path_item_new();
     cairo_t* state = path_item_get_cairo();
     cairo_line_to(state, ...);
     cairo_line_to(state, ...);
   Than to create piles of Line items. Also, piles of 
   Line items won't get the joins right and won't be as 
   efficient.

7. Usable for a compositing manager. This should not really 
   be very hard, I don't think.

8. Data/markup form of the graph; with a GUI editor usable 
   by an artist.

9. Layouts. Parent nodes should have "layout policies" that can 
   be applied to their child nodes (stack, tile, springs-and-struts, 
   hbox, whatever).

The basic idea here would be to make high-quality custom displays much
easier to implement. One kind of custom display is the
window/compositing manager; another is the "middle" of most main
application windows (whether presentation app, UI builder, graphing
calculator, or whatever it is); another might be panel applets or
gdesklets-style thingies.

Havoc