Re: GtkCanvas requirements?

[Damon Chaplin <damon karuna eclipse co uk>]

On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote:
> El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribi� 
> > I'd step back first and do use-cases instead, and also talk about at a 
> > high level what the canvas is for and when it would be used, i.e.:
> 
> Havoc is on the right track here.  You can pile an immense feature list
> on top of the canvas and still get a useless thing.  We need use-cases.
> 
> My use-cases for a canvas:
> 
> - Interactive, pre-drawn graphical content which cannot be done with
> stock widgets.  Think of "using Inkscape instead of Glade"; think of a
> poor man's Flash.  People want to do this:
> 
>   canvas = new Canvas ();
>   svg = canvas.load_svg ("foo.svg");
>   handle = svg.get_object_by_id ("bouncing-ball");
>   handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4));
> 
> - Interactive diagrams, generated programmatically.  Think of "the sexy
> call-graphs in kcachegrind".  A static diagram is trivial, as you can
> just draw it with Cairo *once* and BitBlt() it when you need it.  An
> interactive diagram is harder, since you need event handling, hit
> testing, painless redraw, etc.
> 
> - Simple games are already covered by the points above.

Here's some use-cases mentioned on the GooCanvas list:

 - DTP app (that's what I originally wrote it for).
 - Multi-track audio editor (currently uses GnomeCanvas).
 - Genome viewer (currently uses FooCanvas).
 - Air traffic controller simulator.
 - Database relationship viewer.
 - PIM Synchronizer connection viewer.

So basically it is all kinds of data visualization and manipulation, and
the occasional animation. Plus some WYSIWYG stuff to be printed.


> - I think we want to focus on simplicity and heavy use of SVG.
> Thousands of programmatically-generated items ("music editor", flyweight
> items, etc.) are not very interesting and could complicate the design a
> lot.
> 
> - Whoever does a canvas really really really needs to look at
> Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/).  The animation API is
> lovely, and the support for "zoomable UIs" is lovely as well.  If we had
> Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs
> covered.

I spent quite a while reading through the Piccolo docs before writing
GooCanvas, but I'm afraid I didn't like it that much. The API is
horribly complicated:
  http://www.cs.umd.edu/hcil/piccolo/learn/piccolo/doc-1.2/api/

What was great about the animation API and zoomable UIs? As far as I
could see zoomable UIs just meant using different painting code at
different scales, which isn't that difficult:
  http://www.cs.umd.edu/hcil/piccolo/learn/patterns.shtml#Desing%
20Patterns%20for%20ZUI%20Interaces

I basically copied what they did for their convenience animation
functions, but it didn't work well for rotations so I had to rewrite it.

I thought SVG was a much nicer model.


> [Side note... at this point I think doing a canvas in C is a big
> mistake.  Interesting canvases will inevitably get cycles in the pointer
> graph, and reference counting becomes just too painful then.  [This is
> irrelevant to .net or whatever; it's a general We Should Stop Writing
> Nontrivial Shit In C thing.  People would be really really happy with
> the Piccolo.NET API implemented with pygtk or gtk-sharp.]]

I don't really agree about the reference counting - noone has reported
problems yet.

I don't think C is that bad. GLib and GTK+ are a bit painful at times,
but hard problems are hard in any language.


> The canvas also needs to have performance goals defined up front.  We
> don't want the case where people avoid using the canvas because it is
> too slow (like what happened with the antialiased GnomeCanvas).

GooCanvas has a demo that creates 100,000 items over a large canvas. The
main problem is startup time of about 5 seconds (creating all the items
and measuring text item widths probably). But it works fine after that.

Damon