Re: Porting to GTK+ 3

[Damon Chaplin <damon karuna eclipse co uk>]

On Tue, 2010-06-15 at 17:12 +0200, Brandon Lewis wrote:

> I think you're putting the needs of people writing custom canvas items
> over the needs of the majority who merely want to create objects that
> are compositions of graphics primitives. Moreover, I don't really see
> why it would be more difficult for the author of a custom item to handle
> x, y, width, and height, properties since they have to write a paint
> method as a function of rectangular bounds anyways.
> 
> Moreover, as is pointed out in the bug report, the transform API is not
> equivalent to the x, y, width, and height properties. Setting scale can
> have an adverse effect on rendering of borders and text. In other words,
> the transformation API provides an important but distinct functionality.
> 
> Having a common interface to set the native position and size of objects
> is useful, and I don't think it really matters what the shape is. I find
> it rather annoying that some items (like GooCanvasEllipse) provide an
> alternative but equivalent interface -- because it means re-writing
> application code to change presentation -- while other elements, such as
> GooCanvasText, don't give you this control at all (forcing akward usage
> of th clipping path property, or even worse having to write ac custom
> item). Even for more complicated cases, such as GooCanvasPolyLine, they
> could still exist as read-only attributes, or they could be interpreted
> as a rectangular clipping region (with -1 defaulting to 'native size').

All the builtin items have "x", "y", "width" and "height" properties
now. See:
  http://library.gnome.org/devel/goocanvas/unstable/ch03.html

Did you miss that, or is that still not enough for some reason?

Damon