Re: The state of the canvas

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:
> 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.

> 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

 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]