moose-technology@googlecode.com wrote:
Updates: Status: Fixed
Comment #14 on issue 842 by alexandr...@gmail.com: ROTranslatingShape mouse hotspot mis-alignment http://code.google.com/p/moose-technology/issues/detail?id=842
Hi!
Thanks for your post. It was inspiring. I spent a lot of time on think about the implication about having a translating shape and an offset. Neither approach has convinced me so far.
The reason is the following: shapes are closely dependent from each other, meaning that the element is the only entity subject to layout, looking up subnodes, and responsible for its bounds. This model is quite simple, easy to understand, easy to debug. Adding a concept of offset breaks this nice small model. As soon as you want shapes to be next to each other, you need a kind of layout, at least to say that shape1 is on the left-hand side of shape2. However, layouts work only on elements.
I came to the conclusion to not have translation or offset for shape. The source code has been reverted to the equivalent of what it was a couple of weeks ago. This is not I am against this idea, however I could not find a clean and appealing way to implement it without redesigning the shapes hierarchy. Subclassing ROElement should easily solve your problem although.
I consider this issue as fixed so far.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Fair enough. Thanks for the attempt. I could see a lot of effort went into trying to make it work. The recent example by Vanessa & yourself mixing 'forward' interaction with a VerticalLineLayout will probably satisfy a lot of my current needs. However I just want to lead your thinking in a slight different direction. For the purpose of provoking thought, I take some extreme points of view....
1. It is not entirely true to say "an element is responsible for its bounds" since ROElement>>bounds immediately calls ROShape>>extentFor: Shapes seem to actually end up responsible for an element's bounds.
2. "Shapes are closely dependent from each other" is not necessarily true. I know some of my examples created a high dependency between "shapes relative to other shapes" but I think that was due to a poor approach. I think a conceptual distinction could be made between Elements that require layouts to arrange their position "relative to other Elements", and Shapes which arrange their position only "relative to the owning Element."
3. Saying "Element is the only entity subject to layout" is a bit like saying "Element is the only entity subject to translation." However that is not entirely true. ROAbstractChildrenShape>>drawChildrenOn:for: makes use of translation. In a way I can't quite define, this ChildrenShape architecture makes me uncomfortable. Perhaps it may have something to do with Layout directly affecting the size of a Shape, namely the ROChildrenShape. It is the dynamic size of this component against labels need to aligned top/bottom/left/right/center/etc which creates the "close dependency" between shapes. Perhaps also it is that all the other Shapes eventually call some primitive executed on aCanvas. Whereas the ChildrenShapes don't do any direct drawing themselves but translate the drawing of the other shapes based on the results of the layouts. Perhaps also it is similar to your indication that "ROElement is the only entity subject to looking up subnodes", where this clean concept is broken by ROAbstractChildrenShape>>subElementsAt:forElement: cycling through subnodes.
How about if ROChildrenShape was not a shape, and something else controled cycling through subnodes ?
4. I want to create a ROLabelBelowChildren (similar to my ROCenteredLabel), but currently this is problematic since which bounds do I use? I think it would be very useful (and a clean design) to split the bounds concept into 'childLayoutBounds' and 'outerBounds'. Currently there is no 'childLayoutBounds' and hence (I think...) the 'outerBounds' is determined from the Layout only. However if I then start drawing myLabel at 'outerBounds y', how do I incorporate my label into the outerBounds of the element. I speculate that 'outerBounds := (outerBounds x) @ (outerBounds y + myLabel height)' will end up heading towards infinity due to accumulating from #contains at every mouse movement. What I propose is that outerBounds is determined from Layout plus Shapes.
The execution might look something like... a. Innermost Leaf Elements determine their outerBounds from their shapes only. b. Parent Element applies Layout based on outerBounds of child elements, which sets the Parent's childLayoutBounds. c. Parent's Shapes are independent from any other shape, but may freely offset from childLayoutBounds . d. Parent's outerBounds is determined from the union of childLayoutBounds and Parent's Shapes.
Just food for thought... cheers -ben