Issue 831 in moose-technology: Rossal problem with nested node translation to left of 0@0

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 831 by [hidden email]: Rossal problem with nested  
node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?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.

Attachments:
        Roassal-problem-with-nested-node-translation#1.png  23.5 KB
        Roassal-problem-with-nested-node-translation#2.png  29.6 KB

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #1 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

oh... the test code will help!  It is very slightly modified in the last  
three lines from that used for the attached images, only since I was  
calling a method I hacked in. This example was tested on Roassal.288.


        paramNodeCount := 3.
        translator := ROLayoutTranslator default.
        view := ROView new.
        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,
                        elDynamic bounds origin asString, String crlf,
                        outer1 bounds origin asString
                ] ) .
                outer1 add: el.
                translator translate: el to:  50 * ( n@n ).
        ].
        view add: outer1.

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


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #2 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #3 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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.
------------------


Attachments:
        roassal-issue831-example2.png  28.6 KB

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ben, I will have a look at your email. Since they are about non-trivial things, I need to digest what this involves.

Cheers,
Alexandre


On Sep 10, 2012, at 2:23 PM, [hidden email] wrote:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #4 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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

Attachments:
        Roassal-BenComan.298.mcz  231 KB

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #5 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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?

Attachments:
        roassal-issue831-example3.png  25.4 KB

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #6 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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

Attachments:
        roassal-issue831-example4.png  14.8 KB

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #7 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #8 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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.


Attachments:
        ROExample-addNodes.st  1.6 KB
        Roassal-BenComan.299.mcz  231 KB

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Updates:
        Cc: [hidden email]
        Labels: Component-Roassal

Comment #9 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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?


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #10 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

Is this still an issue?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #11 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

Ben?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #12 on issue 831 by [hidden email]: Rossal problem  
with nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

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)


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #13 on issue 831 by [hidden email]: Rossal problem  
with nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831


I believe operating as per Comment 12 will be much more intuitive to work  
with.
To expand your test method above, if you present the following to a dozen  
random programmers,
what do you think their answer would be for the position of innerNodes 1, 2  
& 3 ?

testDraggingOnTheTopLeftCorner

        | view outterNode innerNode1 innerNode2 innerNode3 result |
        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).
       
        innerNode3 := ROElement new.
        innerNode3 + (ROBox red extent: 10 @ 10).

        outterNode add: innerNode1.
        outterNode add: innerNode2.
        outterNode add: innerNode3.
       
        view add: outterNode.
        " view open "

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

        "Dragging innerNodes"
        innerNode1 translateBy: -10 @ -10.
        innerNode2 translateBy: -10 @ -10.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #14 on issue 831 by [hidden email]: Rossal problem  
with nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

Sorry, correction to comment 12...
assuming outerNode was defined with an extent 5@5, then..
innerNode1 position = (-10 @ -10)
innerNode2 position = (0 @ 0)
outerNode extent = (20 @ 20)
outerNode position = (0 @ 0)
outerNode bounds = (-10 @ -10) corner: (10 @ 10)

In addition, if outerNode is then translatedBy 50@50 you get...
innerNode1 position = (-10 @ -10)
innerNode2 position = (0 @ 0)
outerNode extent = (20 @ 20)
outerNode position = (50 @ 50)
outerNode bounds = (40 @ 40) corner: (60 @ 60)


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #15 on issue 831 by [hidden email]: Rossal problem  
with nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

To refine this a bit more, for the following code, I have mocked up what I  
expect the result should be.  I suppose the actual local-position of the  
inner nodes might not be important, however the element corners  
consistently touching in both positive and negative directions should be.  
In addition, I would expect the same result applying transformer in the  
opposite order.

        | paramNodeCount translator view outer |
        translator := ROLayoutTranslator default.
        view := ROView new @ RODraggable.

        outer := (ROElement spriteOn: '      outer position ' ) + (ROLabel text:  
[ :el2 | el2 model, el2 position truncated asString]).
        3 to: -3 by: -1 do:
        [ :n |
                Transcript crShow: n.
                outer add: ((ROElement spriteOn: n) width: 100; height: 100) +  (ROLabel  
text: [ :el2 | el2 model asString, String crlf, el2 position truncated  
asString ] ) .
        ].
        view add: outer.
        view open.

        outer elements "reverse" do:
        [ :el |
                translator translate: el to: el extent * el model.
        ].

Attachments:
        Roassal-negative-translation-expected.png  22.5 KB
        Roassal-negative-translation-existing.png  33.7 KB
        Roassal-negative-translation-existing-reverse.png  23.6 KB

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #16 on issue 831 by [hidden email]: Rossal problem  
with nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

I think it would simplify things for users if the order that translations  
were applied was not critical. So unless I'm way off base, a suitable test  
might look like this...

testDragging
        |  translator view outer |
        translator := ROLayoutTranslator default.
        view := ROView new @ RODraggable.

        outer := (ROElement spriteOn: '      outer position ' ) + (ROLabel text:  
[ :el2 | el2 model, el2 position truncated asString]).
        -3 to: 3 do:
        [ :n |
                Transcript crShow: n.
                outer add: ((ROElement spriteOn: n) width: 100; height: 100).
        ].
        view add: outer.
        view open.

        outer elements shuffled do:
        [ :el |
                translator translate: el to: el extent * el model.
                el attributes at: #pos put: el position.
        ].

        outer elements shuffled do:
        [ :el |
                translator translate: el to: 0@0.
        ].
       
        outer elements shuffled do:
        [ :el |
                translator translate: el to: el extent * el model.
                self assert: (el position = el attributes at: #pos).
        ].


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #17 on issue 831 by [hidden email]: Rossal problem  
with nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

Further to this, Comment 16 shows all the translations occurring to the  
inner nodes.  A user might reasonably expect that #position of the outer  
node should not be affected - but currently this gets updated when an inner  
node moves int he negative direction.

The following should be appended complete the #testDragging method  
ofComment 16 ...

     self assert: (outer position = 0@0).
     outer attributes at: #bounds put: outer bounds.

     translator translate: outer to: 50@50.
     self assert: (outer position = 50@50).
     self assert: (outer bounds = (outer attributes at: #bounds) moveBy:  
50@50).

     outer elements do:
        [ :el |
                self assert: (el position = el attributes at: #pos).
        ].

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Comment #18 on issue 831 by [hidden email]: Rossal problem with  
nested node translation to left of 0@0
http://code.google.com/p/moose-technology/issues/detail?id=831

Ben, I started to work on the translating shape. I first want to finish  
this before working on another beast, the translation of inner nodes.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev