Re: GtkCanvas requirements?

[Carlos Garnacho <carlos imendio com>]

Hi Federico :),

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

I see this more as a higher level abstraction over the canvas rather
than an intrinsic feature.

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

As I see it, with a higher abstraction on the latter you could get the
former.

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

There are already other pieces of complicate software in GTK+ (for
example, GtkTreeView), which have proved to be quite beneficial, and one
of the reasons is that they're implemented in C, and thus, they were
bindable to other languages. IMHO programming a potentially widely used
piece of software in a higher level language would cut down severely its
user base.

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

hmm, right, what should be a reasonable/feasible goal? visualizing a
bunch of thousand items with little/no noticeable delay? moving a few
tenths/hundreds around? I guess that making performance studies on the
current canvases could help here.

Regards,
   Carlos