Re: Generic positioning



On Mon, 2008-10-27 at 14:16 -0700, Brandon Lewis wrote:
> Armin Burgmeier wrote:
> > On Mon, 2008-10-27 at 18:47 +0100, Murray Cumming wrote:
> >> On Mon, 2008-10-27 at 18:38 +0100, Armin Burgmeier wrote:
> >>> On Mon, 2008-10-27 at 13:52 +0100, Murray Cumming wrote:
> >>>> On Mon, 2008-10-27 at 11:33 +0000, Damon Chaplin wrote:
> >>>>> 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).
> >> What does the anchor default to? Maybe we can just change the default to
> >> get the expected behaviour in most cases. And maybe Damien would accept
> >> that change in some future parallel-install version?
> > 
> > It does even default to GTK_ANCHOR_NW. So it seems to be only a minor
> > issue anyway. Problems arise only when people rely on the generic
> > x/y/width/height behaviour but change the anchor of such items.
> > 
> > Armin
> 
> What about providing an x, y, width, height variant of the stock canvas items, a 
> separate set of generic-positioning properties

This is basically what I did in the first version of the patch (using a
single property instead of separate ones), but it turned out that it
makes things more complicate for the common cases.

> , or a separate interface for 
> setting those properties. I agree that the transform/scale mechanism isn't 
> always what you want because of issues like outline thickness.
> 
> On the other hand, the main reason for having this is to simplify implementation 
> of containers, and we already have an interface for that. Either use group if 
> you don't care about relative position, use table if you want everything in neat 
> rows and columns, or write your own container if you want to do something wacky.

Armin



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