22 Sep
2012
22 Sep
'12
6:38 p.m.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New 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
Fix attached related to the following mail-posts
Also attached are before and after snapshots from
ROExample>>nestingTranslate.
Ben Coman wrote:
I was trying to apply ROTranslatingShape to produce a
label sitting above
the
children nodes. To understand it better how to get what I
need, I made ROExample>>nestingTranslate to show a permutation of the
order
the shapes can be applied. I have attached a screen snapshot and fileout
for
this. The case I am particularly interested in is el3.
The 'el0' case is the reference without any ROTranslatingShape.
When running the example hover near and over the inner elements to view
the
misalignment of the mouse hotspot. I have marked the approximate offset in
green in the snapshot.
I notice that the existing call chain goes...
ROView>>localElementAt:
ROElement>>elementAt:
ROElement>>contains:
ROElemenet>>bounds
ROShape>>extentFor: (union of extent of each shape)
It seems to me the hotspot misalignment is related to
the translation
being
applied at the shape draw level whereas the #contains: checking is done
at the
element level. This relies on the union of the shape extents to set the
element bounds, but I can't see how that extent union could be modified to
account for the translation - particular in the case of a negative
translation
since extents throw away information
about any negative offset.
So I thought perhaps that the element #contains: checking needs might be
better chained through the shaped, so that the translation
could be applied similar to ROTranslatingShape>>chainedDrawOn:for: and
that
this would not cause any/much additional computation since all the shapes
were
being cycled through anyway for #extentFor:
Something like...
ROView>>localElementAt:
ROElement>>elementAt:
ROElement>>contains:
ROShape>>chainedContains:For: (for each shape)
You can see in all case el1 to el8, the child elements have shifted in
relation
to el0.
However the hotspot remains aligned with the location in el0.
I think part of the problem is that ROChildrenShape is a
ROAbstractEndingShape
and is always at the end of the line - so the translation is applied to the
children elements.
Whereas it might work better if the position of the child elements was not
affected by ROTranslatingShape, such that it becomes the reference for the
position of any other translated shapes.
This would require ROChildrenShape be always the first shape of an element,
rather than always be the last shape.
--------------------
The following code snippet...
el := ROElement on: 1.
(el + ROBorder + ROTranslatingShape + ROLabel ) inspect.
produces shapes chained in order of:
ROLabel-->ROTranslatingShape-->ROBorder-->ROChildrenShape.
which seems reversed from what I would intuitively expect reading the code
left
to right.
I think ideally the shape chain would be:
ROChildrenShape-->ROBorder-->ROTranslatingShape-->ROLabel-->RONullShape
Otherwise as in el1 you can see the position of the label is the same as
el0,
since the label has actually been drawn first prior to the translation, and
instead the translation is applied to the border and child elements, the
latter
of which affects the mouse hotspot.
Attachments:
Roassal-BenComan.310.mcz 242 KB
ROTranslatingShape-permutations-mouse-hotspot-broken.png 33.2 KB
ROTranslatingShape-permutations-mouse-hotspot-fixed.png 29.8 KB