Yeah I see whats going on. Lzviewlinkage needs to take scaling into account
but not the x of blueview. This happens to work out with the canvas since its
x/y are almost always 0. Going the other direction is just completely broken.
>>> 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.
Oh and, math is hard :p
On Sep 2, 2010, at 5:41 AM, P T Withington <[email protected]> wrote:
> On 2010-09-01, at 18:39, Max Carlson wrote:
>
>> On 9/1/10 8:22 AM, P T Withington wrote:
>>> This fixes the reported bug, but I'm still not convinced that the math is
>>> completely correct. Unless I misunderstand completely, I feel the
>>> following two assertions should also hold in the supplied test case:
>>>
>>> assertEquals((yellowview.x+redview.x)*blueview.xscale,
>>> redview.getAttributeRelative('x', blueview), "red x in blue")
>>
>> There's a bug in that one - you're not taking the blueview.x into account.
>> This works:
>> assertEquals((yellowview.x+redview.x)*blueview.xscale + (blueview.x),
>> redview.getAttributeRelative('x', blueview), "red x in blue")
>
> Disagree.
>
> The contract of getAttributeRelative is to answer the question: "Given the
> value of an attribute in the source view, what value in the reference view is
> equivalent?"
>
> So, I'm asking, given that redview has an x value of 40, what value of x _in_
> blueview would be equivalent? Blueview's `x` is relative to the canvas, and
> should not be part of the equation when I am comparing redview and blueview.
>
> To put it another way, currently it is the case that:
>
> redview.getAttributeRelative('x', blueview)
>
> and
>
> redview.getAttributeRelative('x', canvas)
>
> return the same value, which can't be right.
>
>
>>> assertEquals((yellowview.x+redview.x)/(- blueview.xscale),
>>> blueview.getAttributeRelative('x', redview), "blue x in red")
>>
>> This one still fails, and I'm not sure why. Instinct sez this has been
>> broken for a long time. Digging...
>
> I think this is related to my question as to whether a view's scale affects
> the view or only it's children. We seem to have an inconsistent
> implementation. You implied that a view's scale should affect it, but if
> that were the case, then blueview really should be at absolute x=20, since it
> has x=10 and xscale=2, but it is at absolute x=10. OTOH, blueview has an
> absolute width of 200, but blueview.width=100. So, we've got a view's scale
> affecting its width/height, but not its x/y.
>
> Either we have to consistently have scale affect all/none dimensions of a
> view, or we have to have a much more complex implementation of
> getAttributeRelative (because it will have to factor out the shared
> ancestor's scale if you are asking about x/y and factor it in if you are
> asking about height/width).
>
> I think this inconsistency is perhaps derived from Adam only thinking about
> the scaling of a view's resource dimensions and not considering how it should
> or should not affect a view's position.
>
