Re: The state of the canvas
- From: Alexander Larsson <alexl redhat com>
- To: Damon Chaplin <damon karuna uklinux net>
- Cc: gtk-devel-list gnome org
- Subject: Re: The state of the canvas
- Date: Mon, 21 Nov 2005 09:53:00 +0100
On Sat, 2005-11-19 at 12:04 +0000, Damon Chaplin wrote:
> 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.
I was thinking maybe at times you want to e.g. recurse over a tree, and
then its nice to know which items can contain children.
> > 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.
Maybe also using CAIRO_HINT_STYLE_NONE will help?
> > 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.
But scrollbars and events are not used for printing output. Nor is
request_update/request_redraw an appropriate model for such output.
Hmmm...
> 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.
That would probably work fine. It should probably also have a rectangle
argument, so you can render just part of the canvas (e.g. for multi-page
printing).
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a war-weary vegetarian rock star with nothing left to lose. She's a
wealthy snooty mechanic trying to make a difference in a man's world. They
fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]