Re: The state of the canvas
- From: Damon Chaplin <damon karuna uklinux net>
- To: Alexander Larsson <alexl redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: The state of the canvas
- Date: Sat, 19 Nov 2005 12:04:56 +0000
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: http://people.redhat.com/otaylor/grid-fitting/
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
people.
> 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.
Damon
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]