- From: Havoc Pennington <hp redhat com>
- To: gtk-devel-list gnome org
- Subject: canvas notes
- Date: Mon, 15 Aug 2005 02:38:25 -0400
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):
Piccolo is BSD-license. Java3D be careful with since it has a
noncommercial use license, I avoided looking at source code or Sun
There's Avalon also I suppose but I haven't read recent things about it.
I see Piccolo was cited here:
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
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
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();
Than to create piles of Line items. Also, piles of
Line items won't get the joins right and won't be as
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,
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
] [Thread Prev