Re: Important: API Change Questions

Charles Goodwin <[email protected]> writes:
>  o  PosChange removal
>     * replaced by trapping x/y puts?
>     * if so, no way to track movement of boxes in a grid
>     * unless grid boxes have x/y put to but not written?

I haven't come up with a good solution for this yet.  But PosChange
never really worked right (for example, if you move to the left ten
pixels and your parent moves to the right ten pixels, you won't get a
PosChange), and making it work "right" imposes a pretty huge
performance hit.  Plus even with a lot of extra bookkeeping I'm still
not really sure how to do it without breaking the perfection of the
"fake root" emulation -- right now (Lithium) PosChange means that your
position changed with respect to the root box, but we no longer have
"root boxes" (or at least a child should never depend on the
root-box-ness of any particular ancestor).

Right now the best idea on the table is to let you "pin" one box to
another so that x.distanceTo(y) is held constant.  However, I'm not
100% sure how to do that, or how to deal with nonsensical stuff like
circular constraints, etc.

BTW, in the case of scrollpane, you can just trap on the .x and .y
properties of the "inner pane".


>  o  SizeChange removal
>     * replaced by trapping width/height?
>     * does core put to width/height when placing/sizing boxes?
>     * if it does, it won't write to min/max values - inconsistent

Yep, we went over this.


>  o  ChildChange/numchildren
>     * everybody prefers ChildAdded/ChildRemoved
>     * ChildChange mandates always checking against indexof(child)
>     * which are you going to go with?

I really don't think this is a crisis.  I'm not dead-set against going
back to ChildAdded/ChildRemoved.  But there are much more important
things to deal with right this moment than a simple naming convention.

  - a