Dan Dennedy: Kino and MLT Developer
Tuesday, 21 May 2019
Home arrow Categories arrow Kino arrow Response to GNOME Application Framework
Main Menu

cross-platform video editor
Media processing framework
Kino and dvgrab
Non-linear DV video editor for Linux
Linux 1394
Firewire drivers for Linux

Syndication Feeds
RSS 2.0 Feed

Dan Dennedy's Facebook profile

Response to GNOME Application Framework  
Friday, 23 July 2004

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?
as well as perhaps a SVG DOM over cairo alternative to canvas:
(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.