Comment #11 on issue 842 by google....(a)ben.coman.com.au: ROTranslatingShape
mouse hotspot mis-alignment
http://code.google.com/p/moose-technology/issues/detail?id=842
A little bit to go. With the following example, the node cannot be dragged
by the blue square. Also any part of the red square outside the black
square cannot be used for dragging.
--------------
| el inner view |
el := ROElement on: 1.
el + ROBorder blue + (ROTranslatingShape offset: 20 @ 20) + ROBorder.
el extent: 100 @ 100.
el @ RODraggable.
el @ ROPopup.
inner := ROElement on: 2.
inner + ROBorder red.
inner extent: 50 @ 50.
inner @ RODraggable.
inner @ ROPopup.
el add: inner.
view := ROView new.
view add: el.
view open
---------------
Just another thought. I wonder if some of the difficulty arises from the
shape being drawn by one code execution path, and then the #extents and
#contains being calculated by another code execution path - and whether
this could be consolidated into one place... since by the end of the
#drawOn:for: method it should know the final position and extent that it
has drawn of itself, it could be required to set a a new 'offset' and
existing ;extents' ivars in ROShape using local co-ordinates. Then all the
#extent and #contains need to do is consider those stored values rather
than doing a different calculation which currently seems not quite aligned.
Also I notice in ROElement>>elementAt: you write "that in local
co-ordinates aPoint = 0@0 refers to the top left of the [element] bounds."
I presume you mean element bounds. Now my thinking might be naive, but I
can't help feeling that this definition will cause difficulties. Since a
shape with negative offset will move the bounds, so will move 0@0 and so
what is the meaning of the negative offset? My thought is that
conceptually, the local co-ordinate 0@0 aligns with the "element position"
where that is not necessarily "element bounds topLeft" ...or are the issues
with doing that way that I don't see.