My question was less about compositing and more about ROCircleLayout, so I've split my response into two posts. About compositing, really I'm not sure yet. However I have a couple of thoughts that may be easier prior to full compositing. Referring to the attached images, you can see that the children shapes overlap the label shape of the parent, and also multiples within the one shape overlap. IT would help to have a way to offset shapes, and as a default the children should be offset below the label. One way to do that would be being able to specify an offset for shapes, and have some way for the user to set up the specific linking of the bounds. For instance, perhaps adding two label shapes at the top with the children nodes below. The user would have to specifically define the offset of the Take for instance this code for Roassal Easel... n1 := ROElement spriteOn: 'XX___'. n1 + (ROLabel new text: #model). n1 + (ROLabel new text: #bounds ). rawView add: n1. ...where the two labels overlap. I think you would gain a lot if you could do something like the following... n1 := ROElement spriteOn: 'XX___'. n1 + (shape1 := ROLabel new text: #model). n1 + (ROLabel new text: #bounds; offset: [ shape1 bottomLeftCorner ] ). rawView add: n1. This should handle shape1 being a multi-line label. As a second stage, there should be some way to add text under the children nodes. The perhaps (only a wild guess) means that ROChildrenShape should not inherit from RONullShape to be forced to appear at the end of the list of shapes. Or perhaps since ROChildrenShape might be more coupled to the internals than other shapes, something like.... n1 := ROElement spriteOn: 'XX___' n1 + (shape1 := ROLabel new text: #model). n1 + (ROLabel new text: #bounds; offset: [ (shape1 bottomLeftCorner) + (n1 childrenShape bottomLeftCorner) ] ). rawView add: n1. Perhaps this is fairly rough - but it at least makes things possible. hope that makes sense :) cheers -ben Alexandre Bergel wrote: <roassal simple composition.png><roassal children overlapping parent label.png>_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Thanks Ben for all the effort you are putting in Roassal.

Alexandre Bergel wrote: You are most welcome. Actually I have been meaning for a while to compliment your leadership of Roassal - by which I mean your enthusiastic and consistent response to discussion. In some respect perhaps I should not have spent time digging into some of corners of Roassal that I have, but you have made it very easy to be drawn in to improving it when I feel contributions are given reasonable consideration. cheers -ben _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

...where the two labels overlap. I think you would gain a lot if you could do something like the following... n1 := ROElement spriteOn: 'XX___'. n1 + (shape1 := ROLabel new text: #model). n1 + (ROLabel new text: #bounds; offset: [ shape1 bottomLeftCorner ] ). rawView add: n1.

Alexandre Bergel wrote: <roassal simple composition.png><roassal children overlapping parent label.png>_______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Thanks. Got to crash right now. Will look at it in the morning.

Alexandre Bergel wrote: _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Thanks for looking at this Alexandre. That is an interesting approach. I had been considering that each shape might just store an offset internally that cold be set. Attached is "ShapeTranslation-20120916a-bencoman.st" containing some simple use cases for ROTranslatingShape as well as "ROTranslatingShape-usecases.png" containing compiled screenshots. Having worked through those use cases, it seems that how the offset shapes affect the element extent needs to be considered - particular in relation to mouse events. For example, if an element is made up of two shapes at opposite corners, then the blank space at the other two corners remains selectable to drag the element, which might not be quite right. So as wild and uninformed speculation... I wonder if rather than the element registering for events, the individual shapes might register for events and forward them on to the element for processing. cheers -ben Alexandre Bergel wrote: <ROTranslatingShape-usecases.png>ROShape subclass: #ROTranslatingShape instanceVariableNames: 'offset' classVariableNames: '' poolDictionaries: '' category: 'RoassalTest'! !ROTranslatingShape methodsFor: 'rendering' stamp: 'BenComan 9/16/2012 13:35'! chainedDrawOn: aCanvas for: aROElement aROElement translateBy: self offset negated. super chainedDrawOn: aCanvas for: aROElement. aROElement translateBy: self offset. ! ! !ROTranslatingShape methodsFor: 'initialize' stamp: 'AlexandreBergel 9/15/2012 09:51'! initialize super initialize. offset := 0 @ 0! ! !ROTranslatingShape methodsFor: 'accessing' stamp: 'BenComan 9/16/2012 11:24'! offset ^ offset value! ! !ROTranslatingShape methodsFor: 'accessing' stamp: 'BenComan 9/16/2012 11:24'! offset: aBlockReturningPoint offset := aBlockReturningPoint! ! !ROTranslatingShape methodsFor: 'accessing' stamp: 'BenComan 9/16/2012 12:35'! usecase1 " self new usecase1 " " More showing how it operates than a use case. Showing that all shapes to the right of ROTranslatingShape are shifted. However cannot drag element using the point just below top border. " | rawView el | rawView := ROView new. el := ROElement new + ROBorder + (ROTranslatingShape new offset: 20 @ 20) + (ROCircle color: Color blue) + (ROBox) . el extent: 50 @ 50. el @ RODraggable. rawView add: el. rawView open! ! !ROTranslatingShape methodsFor: 'accessing' stamp: 'BenComan 9/16/2012 13:19'! usecase2 " self new usecase2 " " At the moment, the prime need for offset capability is showing the parent label above child elements. It is good that when dragging a child element upwards the label also moves up. However the dragging of elements is offset, eg the point just above bottom border does not drag the element. Note the ROBorder that is commented out. Not critical, but it would be good to put border around the ROLabel where it sits above the ROChildrenContainer, except without the bottom of it cutting across child container. Might be useful to be able to re-use that Shape>>draw:For: methods with a custom bounds rather than getting it from the element. " | rawView outer outerLabel | rawView := ROView new. outer := (ROElement on: 'Child nodes should not overlap this heading text') + ROBorder + (ROTranslatingShape new offset: 0 @ -20) + ROLabel "+ ROBorder". 1 to: 6 do: [ :n | outer add: (ROElement spriteOn: n). ]. outer extent: 50 @ 50. outer @ RODraggable. rawView add: outer. ROGridLayout new applyOn: outer elements. rawView open! ! !ROTranslatingShape methodsFor: 'accessing' stamp: 'BenComan 9/16/2012 13:27'! usecase3 " self new usecase3 " " Also later may want to put put labels below the child element area. " | view outer outerLabel | view := ROView new. outer := (ROElement on: 'Child nodes should not overlap this HEADER text. Try menu on view background.'). outerLabel := ROLabel new. outer + ROBorder + (ROTranslatingShape new offset: [ 0 @ (outerLabel heightFor: outer) negated ] ) + (ROLabel new text: [ :el | el model asString]) . 1 to: 2 do: [ :n | outer add: (ROElement spriteOn: n). ]. outer extent: 50 @ 50. outer @ RODraggable. view add: outer. view @ (ROMenuActivable new item: 'Change text' action: [ outer model: 'Child nodes should not overlap this HEADER text even when it dynamically changes to multiple lines'. outer signalUpdate] ). ROVerticalLineLayout new applyOn: outer elements. view open.! ! !ROTranslatingShape methodsFor: 'accessing' stamp: 'BenComan 9/16/2012 13:27'! usecase4 " self new usecase4 " " Dragging elements 1 & 2 upwards moves doesn't overlap labels with outer label - good. However inital layout has element 2 label overlapped by bottoms of element 1. " | view outer outerLabel | view := ROView new. outer := (ROElement on: 'Child nodes should not overlap this HEADER text'). outerLabel := ROLabel new. outer + ROBorder + (ROTranslatingShape new offset: [ 0 @ (outerLabel heightFor: outer) negated ] ) + (ROLabel new text: [ :el | el model asString]) . 1 to: 2 do: [ :n | | el | el := (ROElement spriteOn: n). el + (ROTranslatingShape new offset: [ 0 @ (ROLabel new heightFor: el) negated ] ) + (ROLabel new text: [ :el3 | el3 model asString, ' should not be overlapped' ]). outer add: el. 1 to: 2 do: [ :n2 | | el2 | el2 := (ROElement spriteOn: n*n2). el add: el2. ]. ROHorizontalLineLayout new applyOn: el elements. ]. outer extent: 50 @ 50. outer @ RODraggable. view add: outer. view @ (ROMenuActivable new item: 'Change text' action: [ outer model: outer model, ' even when it dynamically changes to multiple lines'. outer signalUpdate] ). ROVerticalLineLayout new applyOn: outer elements. view open.! ! !ROTranslatingShape methodsFor: 'accessing' stamp: 'BenComan 9/16/2012 13:37'! usecase5 " self new usecase5 " " Maybe later want to put labels below the child element area. Probably want to reference 'ROChildrenShape>>extent' rather than 'outer extent' since other shaps translations may alter the extent of the element. This doesn't opearte as expected, which should be to have three elements laid out in the column " | view outer outerLabel | view := ROView new. outer := (ROElement on: 'Child nodes should not overlap this FOOTER text, even when nodes are added - see menu. '). outerLabel := ROLabel new. outer + ROBorder + (ROTranslatingShape new offset: [ 0 @ (outer extent y) ] ) + (ROLabel new text: [ :el | el model asString]) . 1 to: 2 do: [ :n | outer add: (ROElement spriteOn: n) + ROLabel. ]. outer extent: 50 @ 50. outer @ RODraggable. view add: outer. view @ (ROMenuActivable new item: 'Add node' action: [ outer add: (ROElement spriteOn: 'extra') + ROBorder + ROLabel. ROVerticalLineLayout new applyOn: outer elements. outer signalUpdate ] ). ROVerticalLineLayout new applyOn: outer elements. view open.! ! _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

My question was less about compositing and more about ROCircleLayout, so I've split my response into two posts. I think the main problem I had was that the ROCircleLayout was determining its radius based only on the number of elements and not the size of the elements. So I've come up with a different approach - not quite finished but thought I'd share it now for some feedback. Using the same example from my original post. Existing ROCircleLayout>>doExecute resulting in [1] is due to this... radius := elements size * self scaleFactor. (btw could you change rad to radius anyway - for a while it confused be thinking this was a variable about radians) I found changing to the following gave a better result [2] targetCircumference := 0. elements do: [ :el | targetCircumference := targetCircumference + el bounds extent r ]. radius := targetCircumference / 2 / Float pi. However using 3 or 2 instead of 10 in the third line of that example still has overlaps [3] [4], so I was wondering what your thoughts were. Perhaps a fudge factor at those lower element counts. Also, probably this only works for elements that have the same bounds. With a mix of small and large elements some will probably still overlap - so I am thinking next of a more dynamic circle - that evens out the space between nodes and grows or shrinks the circumference as needed - leading into a force based one, that shifts connected elements around the circle to be closer to more connected elements. cheers -ben [1] ROCircleLayout-original-10nodes.png [2] ROCircleLayout-sumCircumference-10nodes.png [3] ROCircleLayout-sumCircumference-3nodes.png [4] ROCircleLayout-sumCircumference-2nodes.png Alexandre Bergel wrote: