assertEquals((yellowview.x+redview.x)/(- blueview.xscale),
blueview.getAttributeRelative('x', redview), "blue x in red")
According to my calculations, this should be 100: (yx + rx) * bs or (10 + 40) *
2. I have something hacked in that works, but I'm doing some
cleanup/simplification to the code to make this easier to understand in the
future.
On reconsideration, I think we are both wrong. I think it should be -50.
The question being asked is "how far would I have to move in x in the redview's
coordinate system to get to blueview's current x. Blueview's x=0 is at absolute 10.
Redview's x=0 is at absolute 110. Redview is scaled by a factor of 2, so if I move
x=-50 in redview, I should end up at absolute 110 + (-50 * 2) === 10, which is where
blueview's x is.
Looking at it another way, since the dimensions of views read out as their
unscaled values, when you are calculating a relative attribute, you only need
to factor in scaling if the views being compared do _not_ share the scaling
factors. In this case, yellowview and redview are both governed by the same
scale factor (of blueview) so it's not even part of the equation.
Yeah, I think you're right. This isn't very useful though, because what
you most likely want to do is move blueview to a position that matches
redview. In which case I suppose you'd use the reverse method...
The thing that still mystifies me:
blueview.width === 100
Really? I get 110 pixels back - at least with my patch applied:
>>> blueview.width
110
>>> blueview.getBounds().width
220
You have to use getBounds() to get the true bounds which is what the
bgcolor is using to size to 220. I'll include this in the updated
lztest-view.lzx
but in absolute terms, it is 200 pixels wide.
blueview.x === 10
and that's were it is in absolute terms, 10 pixels down.
which seems correct.
A full review is forthcoming...
