moose-technology@googlecode.com wrote:
Updates: Status: Fixed Cc: alexandr...@gmail.com Labels: -Type-Defect Type-Enhancement Component-Glamour Milestone-5.0
Comment #12 on issue 900 by tu...@tudorgirba.com: Glamour-Roassal should be able to work with raw ROView not just ROMondrianBuilder http://code.google.com/p/moose-technology/issues/detail?id=900
Thanks Ben.
I integrated your solution for now with one modification: we have initializeView: instead of newViewBlock:.
We can iterate from this point on: we need to make all builders polymorphic.
Now, this works:
GLMWrapper new with: [ :browser | browser show: [ :a | a roassal initializeView: [ ROView new @ RODraggable ] ; painting: [ :view :numbers | numbers do: [ :number | view add: (ROElement spriteOn: number) + ROLabel ]. ROTreeLayout on: view elements ] ] ]; openOn: (1 to: 10)
Cool. #initializeView: is a good change. I was never completely happy with my choice, but could not think of better.
Following on from that I have been considering how to have a permanent ROView that does not get replaced by a #new one each transmission. For example, if there are two panes (list-pane & roassal-pane) the double-clicking on items in the list-pane could add them to the roassal-pane, then the could drag it around, then add a second item from the list-pane, and so on...
So I wonder about some like... | roview | GLMWrapper new with: [ :browser | browser show: [ :a | a roassal initializeView: [ roview ifNil: [ roview := ROView new @ RODraggable ] ] ; painting: [ :view :numbers | numbers do: [ :number | view add: (ROElement spriteOn: number) + ROLabel ]. ROTreeLayout on: view elements ] ] ]; openOn: (1 to: 10)
but that seems a bit hackish. Maybe using #andShowIfNone: would be better and transmitting the strong selection from the list-pane to the roassal-pane a different port - maybe an #add port could be matched with a #delete port or something. What do you think?
cheers -ben