Comment #11 on issue 842 by google....@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.