Re: The state of the canvas

On Fri, 2005-11-18 at 14:28 +0100, Alexander Larsson wrote:

> Why don't you split the group only methods from GooCanvasItemIface into,
> say GooCavnasCompositeItemIface. Right now you can call
> goo_canvas_item_add_child() on any item, but it will crash since
> iface->add_child is NULL.

I could split the interface, but I'd have to split the view interface as
well. I'm not sure it would help that much though.
Maybe just outputting a warning would be enough.

> For the text object it would be very nice to have a mode where the text
> is zoomlevel independent. As a very easy way to do this, use
> CAIRO_HINT_METRICS_OFF for the text layout. Ideally you'd do the full
> thing described at:

Yes, zoom-level-independent layout is essential, and is one of my main
worries. I hadn't spotted CAIRO_HINT_METRICS_OFF, so thanks for that.
Unfortunately it doesn't seem to work for me. Maybe since it is only a
hint it isn't guaranteed to work. I'll have to check with the cairo

> There is no support for applying generic affine transformations to the
> items. Maybe this is a design decision though? Adding affines to
> gnome-canvas was certainly when it started going downhill, which is why
> I backed up to before that when I did foocanvas. However, with cairo
> instead of libart for the rendering and all rendering being done with
> cairo this might be doable in a sane way these days.

I wasn't sure I was going to add them to the basic items. But I think
I'll add them to everything, like Piccolo.

> Its a shame that GooCanvasView is not an interface. Its used by
> GooCanvasItem in create_view, so the items are tightly tied to it. If it
> was an interface then you could implement a different view for e.g.
> drawing to a pdf surface (i.e. support printing).

I thought it was more appropriate to subclass GooCanvasView rather than
use interfaces, since it is mainly concerned with widget-related stuff -
handling scrollbars & events.

I think I'm going to change the create_view() functions, and use
something like a 'GooCanvasViewFactory' since the application may want
to use a custom view, and will need to hook up signals for the events.

I'll probably add a render_to_cairo (cairo_t*) function to render to an
arbitrary cairo object.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]