Rossal problem with nested node translation to left of 0@0

[seandenigris]

Originally reported on Google Code with ID 831

The way negative translation is handled for nested elements is causing
havoc as I was try to put some new tricks into ROCircleLayout.  I now perceive this
as a bug which I have distilled below.   

Review to the attached image #1 that was produced by the code listed below. I would
expect that the three 'negative' squares would be spaced symmetrically to the three
'positive' squares.  In attached image #2 element '-3' was moved to the left.  Observe
how the origin of element '-3' remains constant at 0@0 while the origin of elements
'-2' and '-1' are modified as the left border is pushed further left.  In effect, 
this behaviour appears to be the root cause of the 'non-symmetrical' behavior that
is causing me grief.

I believe that as element '-3' is dragged into the negative, the origin of '-3' should
go negative leaving the origins of '-2' and -'1' unchanged.  Let the parent node take
care of the overall translation of its nested elements to keep the 'negative' elements
in view.  The overall visual effect of moving a node into a negative position should
be unchanged, except that conceptually the 0@0 point will be drifting into the middle
of the parent element rather than remaining fixed at the top left.

By way of example, I believe the effect of this on ROCircleLayout>>doExecute would
be to remove all references to the 'center' variable.

This is with Roassal.283.

Reported by benjamin.t.coman on 2012-09-04 15:31:09

---

- _Attachment: Roassal-problem-with-nested-node-translation#1.png
_ - _Attachment: Roassal-problem-with-nested-node-translation#2.png
_

[seandenigris]

With the fix correcting the dynamic bounds of ROLabel, the use of #bounds in the previously
supplied test code causes recursion.  Deleted that test code and replaced with the
code below.

    | paramNodeCount translator view outer1 el  outer2 offset |
    paramNodeCount := 2.
    translator := ROLayoutTranslator default.
    view := ROView new @ RODraggable.

    outer2 := (ROElement spriteOn: '      outer negative translation' ) + ROLabel .
    (1 to: paramNodeCount) do:
    [   :n |
        Transcript crShow: n.
        el := (ROElement spriteOn: n negated) .
        el addShape: (ROLabel text: 
        [   :elDynamic | 
            n negated asString, String crlf, 
            outer2 position asString, String crlf, 
            elDynamic position asString 
        ] ) .
        outer2 add: el.
        offset := -50 * ( n@n ).
        translator translate: el to: offset .
    ].
    view add: outer2.

    outer1 := (ROElement spriteOn: '      outer positive translation') + ROLabel .
    (1 to: paramNodeCount) do:
    [   :n |
        Transcript crShow: n.
        el := (ROElement spriteOn: n).
        el addShape: (ROLabel text: 
        [   :elDynamic | 
            n asString, String crlf, 
            outer1 position asString, String crlf, 
            elDynamic position asString 
        ] ) .
        outer1 add: el.
        offset := 50 * ( n@n ).

        translator translate: el to: offset .
    ].
    view add: outer1.

    view openInWindow.

Reported by benjamin.t.coman on 2012-09-10 16:12:38

[seandenigris]

Just another example perhaps a bit quicker to follow.  In the attachment, Image A is
the reference being all translations in the positive direction for e11, e12 & e13.
 Image B is what I believe should be the result for e21, e22 & e23, where the relative
orientation of e21 & e22 remains the same as e11 & e12.  However the current results
is Image C. Image D shows the result is different if the two translator lines for el23
& el22 are swapped in order.  Whereas I think it  would be good if the resulting layout
was independent of the order that the translates are executed.

I am trying to chase this down myself, and it seems to me that the culprit is in ROAdjustSizeNesting>>on:
where a negative top left corner is relocated back to 0@0, but I need to do more to
understand what is happening.

cheers -ben

--------------------
    | paramNodeCount translator view outer1 outer2 el  offset el11 el12 el13 el21 el22
el23 |
    paramNodeCount := 2.
    translator := ROLayoutTranslator default.
    view := ROView new @ RODraggable.

    outer1 := (ROElement spriteOn: '       outer1' ) + ROLabel .
    outer1 add: (el11 := (ROElement spriteOn: 11) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) @ RODraggable ).
    outer1 add: (el12 := (ROElement spriteOn: 12) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) @ RODraggable ).
    outer1 add: (el13 := (ROElement spriteOn: 13) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) @ RODraggable ).

    outer2 := (ROElement spriteOn: '       outer2' ) + ROLabel .
    outer2 add: (el21 := (ROElement spriteOn: 21) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) @ RODraggable ).
    outer2 add: (el22 := (ROElement spriteOn: 22) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) @ RODraggable ).
    outer2 add: (el23 := (ROElement spriteOn: 23) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) @ RODraggable ).

    "Sprites default to extent 50@50.  e11 & e21 positioned at 0@0"
    translator translate: el13 to: (200@200) .
    translator translate: el12 to: (50@50).

    translator translate: el23 to: (200@200) negated.
    translator translate: el22 to: (50@50) .

    view add: outer1.
    view add: outer2.
    ROHorizontalLineLayout on: view elements.
    view openInWindow.
------------------

Reported by benjamin.t.coman on 2012-09-10 17:23:12

---

- _Attachment: roassal-issue831-example2.png
_

[seandenigris]

Roassal-BenComan.298 partial solution to child element negative translation. Position
of elements good. Size of parent element not quite right.  Dragging not working. 

Reported by benjamin.t.coman on 2012-09-11 15:23:49

---

- _Attachment: [Roassal-BenComan.298.mcz](https://storage.googleapis.com/google-code-attachments/moose-technology/issue-831/comment-4/Roassal-BenComan.298.mcz)_

[seandenigris]

Just adding a screenshot of the "partial solution" of comment 4.  Notice that within
the 'negative' parent element, the individual child elements are touching and in the
expected order.  However the bounding box of the 'negative' parent element is too large
and the children as a group offset is too much.  

Also the 'negative' child elements cannot be dragged.  Is there a way to get from each
element the bounds that it is using to receive events, such that it can be drawn on
the canvas for debugging purposes?

Reported by benjamin.t.coman on 2012-09-15 08:52:04

---

- _Attachment: roassal-issue831-example3.png
_

[seandenigris]

Another screenshot using test code from comment 3 with mcz from comment 4.

Reported by benjamin.t.coman on 2012-09-15 08:56:36

---

- _Attachment: roassal-issue831-example4.png
_

[seandenigris]

Just deleted comment 3 to update the code to remove the erroneous extra @RODragable
applied to each sprite - since they are already draggable.
------------------------
Just deleted comment 3 to update the code to remove the erroneous extra @RODragable
applied to each sprite - since they are already draggable.

Just another example perhaps a bit quicker to follow.  In the attachment, Image A is
the reference being all translations in the positive direction for e11, e12 & e13.
 Image B is what I believe should be the result for e21, e22 & e23, where the relative
orientation of e21 & e22 remains the same as e11 & e12.  However the current results
is Image C. Image D shows the result is different if the two translator lines for el23
& el22 are swapped in order.  Whereas I think it  would be good if the resulting layout
was independent of the order that the translates are executed.

I am trying to chase this down myself, and it seems to me that the culprit is in ROAdjustSizeNesting>>on:
where a negative top left corner is relocated back to 0@0, but I need to do more to
understand what is happening.

cheers -ben

--------------------
    | paramNodeCount translator view outer1 outer2 el  offset el11 el12 el13 el21 el22
el23 |
    paramNodeCount := 2.
    translator := ROLayoutTranslator default.
    view := ROView new @ RODraggable.

    outer1 := (ROElement spriteOn: '       outer1' ) + ROLabel .
    outer1 add: (el11 := (ROElement spriteOn: 11) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) ).
    outer1 add: (el12 := (ROElement spriteOn: 12) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) ).
    outer1 add: (el13 := (ROElement spriteOn: 13) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) ).

    outer2 := (ROElement spriteOn: '       outer2' ) + ROLabel .
    outer2 add: (el21 := (ROElement spriteOn: 21) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) ).
    outer2 add: (el22 := (ROElement spriteOn: 22) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) ).
    outer2 add: (el23 := (ROElement spriteOn: 23) + (ROLabel text: [ :my | my model asString,
String crlf, my position asString ] ) ).

    "Sprites default to extent 50@50.  e11 & e21 positioned at 0@0"
    translator translate: el13 to: (200@200) .
    translator translate: el12 to: (50@50).

    translator translate: el23 to: (200@200) negated.
    translator translate: el22 to: (50@50) .

    view add: outer1.
    view add: outer2.
    ROHorizontalLineLayout on: view elements.
    view openInWindow.
------------------ 

Also, referring to example4.png, just another thing where I notice my 298.mcz is not
correct is shown by dragging the '0@0' element in 'outer 1'.  Moving it in the positive
direction is fine, moving in line with the cursor, but moving in the negative direction
the element doubles in speed. Also the 50@50 and 200@200 nodes should remain stationary
but instead move in the negative direction.

Reported by benjamin.t.coman on 2012-09-15 11:30:17

[seandenigris]

To aid debugging, I created ROExample>>addNodes which interactively adds nodes one at
a time - see attached.    Not sure if this is critical, but it is interesting to compare
the behaviour of Roassal.AlexandreBergel.294.mcz with Roassal.BenComan.299.mcz.

1. With 294 run addNodes, rightclick element 'outer positive' and select menu item
'Add +VE node' several times.  Observe the corners of the boxes align neatly.  

2. Next with 294 start a new addNodes,  and alternate between moving element 'outer
positive' to the side, and adding a +VE node. Repeat several times. Observe that the
corners of the boxes are no longer aligned - due to the position of the earlier boxes
being shifted.

3. Load 299 and repeat step 2.  Observe how the corners of the inner nodes align. I
think this is 'almost' a better result, except I just need to work out how to avoid
the outer node from resetting back to 0@0 - which might also solve part of the problem
for elements moving in the negative direction.

Reported by benjamin.t.coman on 2012-09-15 17:25:17

---

- _Attachment: [ROExample-addNodes.st](https://storage.googleapis.com/google-code-attachments/moose-technology/issue-831/comment-8/ROExample-addNodes.st)_ - _Attachment: [Roassal-BenComan.299.mcz](https://storage.googleapis.com/google-code-attachments/moose-technology/issue-831/comment-8/Roassal-BenComan.299.mcz)_

[seandenigris]

Ben, I find that the examples are a bit difficult to understand. I propose a test method
that is green in the last version of Roassal.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
testDraggingOnTheTopLeftCorner
    | view outterNode innerNode1 innerNode2 |
    view := ROView new.
    view @ RODraggable.

    outterNode := ROElement new.
    outterNode + (ROBox new extent: 50 @ 50).

    innerNode1 := ROElement new.
    innerNode1 + (ROBox blue extent: 10 @ 10).

    innerNode2 := ROElement new.
    innerNode2 + (ROBox green extent: 10 @ 10).

    outterNode add: innerNode1.
    outterNode add: innerNode2.

    view add: outterNode.
    " view open "   

    "Witout dragging"
    self assert: innerNode1 position = (0 @ 0).
    self assert: innerNode2 position = (0 @ 0).

    "Dragging innerNode"
    innerNode1 translateBy: -10 @ -10.
    self assert: innerNode1 position = (0 @ 0).
    self assert: innerNode2 position = (10 @ 10).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

What do you think the position of innerNode1 and innerNode2 should be?

Reported by alexandre.bergel on 2012-09-16 01:42:14

• Labels added: Component-Roassal

[seandenigris]

Is this still an issue?

Reported by tudor@tudorgirba.com on 2012-09-23 20:38:13

[seandenigris]

Ben?

Reported by alexandre.bergel on 2012-09-24 15:20:28

[seandenigris]

I think this is still a problem.  I'll explain further in another post shortly.
To answer your question, I think the result should be...
innerNode1 position = (-10 @ -10)
innerNode2 position = (0 @ 0)
outerNode position = (-10 @ -10)
outerNode bounds = (-10 @ -10) corner: (0 @ 0)
outerNode extent = (10 @ 10)

Reported by benjamin.t.coman on 2012-09-24 15:57:04