Re: Generic positioning

[Armin Burgmeier <armin arbur net>]

On Wed, 2008-10-29 at 12:37 +0000, Damon Chaplin wrote:
> On Tue, 2008-10-28 at 20:29 +0100, Armin Burgmeier wrote:
> > On Mon, 2008-10-27 at 11:33 +0000, Damon Chaplin wrote:
> 
> > > My main problem with this is that if we are going to add x, y, width &
> > > height properties to the GooCanvasItem interface then they should have
> > > well-defined semantics. But they don't - the x and y properties refer to
> > > arbitrary points in the item and the width & height may or may not be
> > > the exact width & height of the item.
> > > 
> > > I would think that if people see generic x, y, width & height properties
> > > then they will expect them to refer to the top-left coordinate and the
> > > exact width & height of the item.
> > 
> > What do you mean with the _exact_ width & height, by the way? Is this
> > because the width of a rectangle, for example, does not cover the entire
> > border? If so, then I think changing that would also break
> > compatibility. Does this matter?
> 
> I meant the complete enclosing rectangle of the item. Generic
> positioning and resizing isn't that useful unless you know exactly what
> coordinates you are dealing with.
> 
> But you're right, it does break compatibility, so I don't want to do
> that.
> 
> 
> I'll accept a patch that adds x, y, width & height properties to most of
> the items that don't have them, with functionality as in your latest
> patch. I don't want to add x, y, width & height properties to the
> GooCanvasItem interface though.
> 
> For GooCanvasGroup I'd prefer it if the x & y properties set the origin
> of the existing transformation matrix rather than adding an extra
> translation.

Wouldn't this make it impossible to get back the x and y properties in
get_property() then? I mean, if the group is translated via
goo_canvas_item_translate, then this should not add up to the x & y
properties (to behave the same was as GooCanvasRect, for example),
should it?

>  I'm not sure about adding width & height though - I'd
> prefer not to. (Your code for GooCanvasGroup looks wrong as it uses
> goo_canvas_item_get_bounds() to get the child extents, but the bounds
> are in device space so may have arbitrary transformations on them.)

What code do you mean exactly? I added test code for the group width &
height to generic-position-demo.c, and everything behaves as I'd expect,
I think.

> For GooCanvasText I'd prefer to use pango_layout_set_height() for the
> height of the text, but that is a relatively new function and I don't
> want to depend on Pango 1.20 yet. Maybe we could use our own code to
> only draw lines of text that are completely visible using the given
> height.

I'll try this out.

> Damon

Armin