Comment #2 on issue 831 by google....(a)ben.coman.com.au: 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.

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, moose-technology(a)googlecode.com wrote: -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Comment #5 on issue 831 by google....(a)ben.coman.com.au: 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

Comment #7 on issue 831 by google....(a)ben.coman.com.au: 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.

Updates: Cc: google....(a)ben.coman.com.au Labels: Component-Roassal Comment #9 on issue 831 by alexandr...(a)gmail.com: 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?

Comment #11 on issue 831 by alexandr...(a)gmail.com: Rossal problem with nested node translation to left of 0@0 http://code.google.com/p/moose-technology/issues/detail?id=831 Ben?

Comment #13 on issue 831 by google....(a)ben.coman.com.au: 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.

Comment #15 on issue 831 by google....(a)ben.coman.com.au: 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

Comment #17 on issue 831 by google....(a)ben.coman.com.au: 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). ].

Updates: Cc: alexandr...(a)gmail.com Comment #19 on issue 831 by tu...(a)tudorgirba.com: 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?

Comment #21 on issue 831 by benjamin...(a)gmail.com: Rossal problem with nested node translation to left of 0@0 http://code.google.com/p/moose-technology/issues/detail?id=831 I believe this was not related to the shape translation experiment, so is I partially think it still an issue. However it is not directly affecting me at the moment so WontFix is fine for now. If it crops up again I'll try to attack it from another direction first.