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: > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by moose-technology
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 |
Free forum by Nabble | Edit this page |