Re: Generic positioning



On Mon, 2008-10-27 at 13:52 +0100, Murray Cumming wrote:
> On Mon, 2008-10-27 at 11:33 +0000, Damon Chaplin wrote:
> > On Tue, 2008-10-21 at 23:55 +0200, Murray Cumming wrote: 
> > > We now have a patch for generic positioning in goocanvas. This puts x,
> > > y, width, and height properties on the GooCanvasItem base interface,
> > > without changing the behavour of existing x, y, width and height
> > > properties where they already exist on some items. So it's not an API
> > > change - just an API addition or simplification.
> > > 
> > > This allows applications to move and resize items without special code
> > > for each type of item. The generic-position-demo shows how this can be
> > > useful.
> > > 
> > > This is simpler than working with transforms and, unlike transforms, it
> > > does not also affect details such as rectangle borders or specified text
> > > sizes.
> > > 
> > > I'd like this patch to be considered, please.
> > > http://bugzilla.gnome.org/show_bug.cgi?id=555097
> > 
> > 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.
> 
> I don't personally feel that's necessary, but I guess we can achieve
> that. Armin, could you try that, please?

Yes, but as explained in the bug this would break compatibility for
items that already have "x" and "y" and behave differently (such as
GooCanvasText or GooCanvasWidget when the "anchor" property is not
GTK_ANCHOR_NW).

> > I wouldn't mind adding x, y, width & height properties to some of the
> > items though.
> > 
> > 
> > If I was writing an application that allowed users to drag items around
> > and snap them to grids etc. I'd write my own custom items derived from a
> > base class that supported drag-handles and all the API necessary to do
> > this generically.
> 
> Yes, this must be done too, but the generic positioning makes it easier
> to implement this.
> 
> Note that I think things like those drag handles should be in a library
> somewhere, though probably not in goocanvas.
> 
> >  I wouldn't really expect the builtin canvas items to
> > be usable for this, since the functionality desired will probably differ
> > from application to application.
> > 

Armin



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]