18 Dec
2013
18 Dec
'13
5:50 p.m.
moose-technology(a)googlecode.com wrote:
Updates:
Status: Fixed
Cc: alexandr...(a)gmail.com
Labels: -Type-Defect Type-Enhancement Component-Glamour Milestone-5.0
Comment #12 on issue 900 by tu...(a)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