I sent the following response to Todd Berman's request for comments on the GNOME application framework:

I read your blog post requesting feedback about the GNOME application framework. I am a lead developer of Kino video editor. We are not currently using GnomeCanvas, but we are about to as part of a rewrite. I am concerned about the state of GnomeCanvas within the framework. For various reasons, there are several forks or derivatives of the canvas: mainline libgnomecanvas, DiaCanvas, FooCanvas, sodipodi's, and others? Is that a sign? What is the story with canvas now with Cairo in the picture?
See
http://mail.gnome.org/archives/desktop-devel-list/2004-July/msg00048.html
and
http://mail.gnome.org/archives/gtk-devel-list/2003-September/msg00027.html
as well as perhaps a SVG DOM over cairo alternative to canvas:
http://www.xsvg.org/
(I don't think there is anything close to supporting SVG DOM there, but could a new DOM use an XmlNodeWriter to drive libsvg for rendering?)

If I am just now embarking on a major investment of effort to develop something canvas-based, what direction should I take?

In general, I am very pleased with GTK and GNOME. However, I also have reservations about gstreamer, but that is a somewhat controversial topic. Suffice it to say, we won't use it except maybe as an end producer (source) and consumer (sink) in our own new framework, MLT. In only six months of development, our framework already provides more of what we need and in a more stable manner. gstreamer progress seems too slow, has grown too complex, and has not produced enough stable intermediate versions. The concern is that if I were to attempt to develop the Kino rewrite atop gstreamer, then I would end up putting too much effort into gstreamer while not yielding enough gratifying results.