Re: GtkCanvas requirements?

[Federico Mena Quintero <federico ximian com>]

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.

- 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.

[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.]]

>   - when is a canvas item used vs. a widget? what current widgets would
>     be "replicated" as canvas items?

If you have a stock canvas item for editable text, you already have 95%
of the cases covered --- you can compose "editable" mega-items out of
that text item plus decoration.  That's what we do in the Evolution
calendar, for instance:  the calendar's appointments are just a bunch of
boxes and lines plus text items.

Putting GtkWidgets inside a canvas is a nice gimmick, but I don't think
you need to make them fully zoomable/transformable/etc.  If you want
GtkFixed-like layout with canvas drawings underneath, you don't need
exotic transformations.

(People often do diagrams which need pushable buttons, and so they want
to stick a GtkButton inside a canvas.  For that it may be simpler to
just create a CanvasButton object which you can decorate to your heart's
content with SVG.)

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).

  Federico