Re: GTK-Canvas

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Ter, 2006-02-28 at 12:42 -0500, Havoc Pennington wrote:
> On Tue, 2006-02-28 at 16:33 +0000, Gustavo J. A. M. Carneiro wrote:
> > 
> >   That sounds complicated to get right in one go.  Personally, I'd just
> > be happy to have a canvas that lets you create items, with virtualized
> > draw method, even at position/size statically controlled by the
> > programmer, stacking/layering and events.  Basically like GnomeCanvas.
> > If we get that right, and optimise the redrawing properly using micro
> > tile arrays like in GnomeCanvas, then we can put that in gtk+ 2.10 right
> > away.  It seems to me like everything else is either not so important
> > that can't wait a bit more (like embedding widgets) or can be done on
> > top of the existing framework (animations, layout, object graph file
> > persistency).
> > 
> 
> Maybe so. I feel like we kind of stopped using GnomeCanvas though,
> because it just wasn't that much more useful than a drawing area, and
> had its own kind of complexity and limitations ... retained mode in
> particular adds the problem of keeping the retained graphics state in
> sync with the state of the app, while with non-retained mode when the
> app state changes you just queue_draw() and that's it.

  I think this is why GnomeCanvas failed too, but the precise reason
seems to ellude everyone.  You seem to think in terms of reimplementing
the GnomeCanvas model of having many "Canvas Items", one for each
shape--circle, polygon, text, etc. -- and let canvas item composition be
used to accomplish more complex shapes.  Of course this model is
tedious, you have to keep adding and removing canvas items in order to
modify how objects look.

  My proposal would be rather different.  Have a single CanvasItem
object, which would emit a "draw" signal with a cairo_context_t as
argument.  Also define a queue_draw method, like in gtk+ widgets.  Then
let programmers simply connect a handler to that signal--or even
override the class virtual--and draw _whatever they want_ based on
application document model.  This has several advantages:
	1- The programmer can direclty map document objects to canvas objects;
	2- The programmer can use the full cairo API, instead of being
restricted by the available shapes;
	3- No need to keep adding/removing items to change appearance of
objects;
	4- It is rather intuitive for people used to program gtk widgets or
with GtkDrawingArea.

> 
> The two exciting features of GnomeCanvas really were antialiasing and
> lack of flicker, and a drawing area has both of those now. The only
> other thing the canvas really does for you is event handling on objects,
> but GnomeCanvas wasn't that convenient for that because the hard part
> really is coding the grab handling and such (behaviors).

  True.  I think behaviours are important but, if I had to choose to
leave behaviours out in order to have a basic canvas in gtk+ 2.10, I
wouldn't hesitate.  Keep in mind that having interactable objects in a
canvas is just one part of what the canvas can do.  For me, the canvas
is more important because it allows you to have complex graphics in gtk+
that are both fast (no need to redraw everything all the time) and don't
necessarily take lots of X server memory (no need to draw everything
once to an offscreen pixmap in order to avoid redrawing complex graphics
while something is being dragged over your widget).  And of course that
you can selectively redraw an object inside the canvas, instead of
calling queue_draw and then forcing all the objects to redraw
themselves.

> 
> Also, I'm not sure all the cool features can be done on top, at least
> not while keeping a nice simple API. Or put differently, maybe the API
> can be better if it's a bit higher level than "put a line here and a
> circle there" - think about making the XML format the primary usage
> pattern, with subsequent manipulation from code, sort of like a web
> page.

  Hhm.. cool, but not nearly as useful as having a way to draw complex
graphics in gtk+ and be able to print them without losing vectorial
quality.

> 
> It's not like all my wishlist items are star trek hard - behaviors and
> animations in particular seem pretty manageable, and for widget
> embedding Alex already sorted out the hard bits.
> 
> Just trying to cheerlead some ambitious goals ;-)

  All those features are nice, but I'm afraid that we might end  up not
getting anything into gtk+ 2.10 if we aim for too much, and I'd really
really love to have a canvas in gtk+.

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic