Re: Porting to GTK+ 3

[Brandon Lewis <brandon collabora co uk>]

On Tue, 2010-06-15 at 17:00 +0100, Damon Chaplin wrote:
> 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?
> 

I remember having seen patches submitted for that, but I didn't realize
it had been merged.

> Damon
> 
> 
> 
>