[cairo] Re: Goocanvas: trivial patch, and a request for a "cairo" item

[Damon Chaplin]

On Tue, 2006-11-28 at 23:55 -0800, Carl Worth wrote:

> The first problem I had in trying to use it is that in the source that
> I found [*] it's not installing any header files. The fix for that is
> a silly little typo for which a patch is attached below.
> 
> If cairo's CVS is still the canonical place for this source to live,
> (it seems somewhat active---commits as recent as October), then I'd
> be glad to just commit this fix if you don't mind. Or if the source is
> now hosted somewhere else, please let me know so we can get rid of the
> old source here.

Yes, I still use cairo's cvs. Though I've been working on a major
rewrite of GooCanvas lately which I haven't committed yet.

You can commit the fix if you like. (I have the same fix here, I just
forgot to commit it.)


> Next, I wonder if there's a way to create a canvas item for which I
> can define a custom drawing function. That's what I'd really like in
> an interface. For example, the first canvas items I want to draw are
> letters that appear to be engraved in little spheres or something like
> that. I should be able to come up with a sequence of cairo operations
> that draw the shape I want, (or some lame approximation that someone
> with real artistic ability will be able to fix for me). And I'd like
> to implement that as a callback or so for some "custom cairo" canvas
> item, (accepting a cairo_t*, width, and height or so).
> 
> Then presumably I'd also also need to be able to tell this canvas item
> what its "shape" is for input selection. So maybe I would implement a
> function that sets a path in a cairo context to describe that, (and by
> default I would just get the bounding rectangle).
> 
> Does what I'm getting at make sense? I would imagine it shouldn't even
> be that difficult for someone who already understands the inheritance
> stuff for glib objects and the interfaces for goocanvas items.
> 
> Basically, what I'd love to see is something just like simple-demo.c
> but instead of:
> 
>   rect_item = goo_canvas_rect_new (root, 100, 100, 400, 400,
>                                    "line-width", 10.0,
>                                    "radius-x", 20.0,
>                                    "radius-y", 10.0,
>                                    "stroke-color", "yellow",
>                                    "fill-color", "red",
>                                    NULL);
> 
> I would want to have something like:
> 
>   rect_item = goo_canvas_cairo_new (root, 100, 100, 400, 400, draw_rect);
> 
> where draw_rect is a function that accepts a cairo_t and makes the
> calls into cairo to draw the item.
> 
> That's the kind of interface I would like to see in a cairo-based
> canvas.

I'm afraid GooCanvas has a more object-oriented design - you need to
create new classes for each new type of item.

It would be possible to create a new class that accepted callback
properties for drawing the item, doing hit detection, and calculating
the bounds. But this only sounds useful for fairly simple, static items.

For more complicated, dynamic canvas items you'd have other properties
that could be changed so you'd need you're own class anyway really.

If you subclass from the simple item, it is fairly easy to create a new
canvas item - you just override the update(), get_item_at() and paint()
methods. (These do the bounds calculation, hit detection, and drawing
respectively.)

I could write a script that outputs the skeleton of a new class, where
you just need to fill in the drawing code etc.


(As I said above, I've been working on a major rewrite lately, so a lot
of the API is about to change. I'll try to commit the new stuff later
today.)

Damon