Hi Ben,

You raise a good point: how to update the visualization without redrawing it. This is particularly important if you want to animate or adjust animations from outside.

In the Glamour spirit, it is the job of the transmission to clear or not the target pane. For example, in the case of an accumulator browser, you want to use andShowIfNone: rather than andShow:. Like this, you only install the presentation the first time, and afterwards you reuse it.

For example:

GLMCompositePresentation new tabulator with: [ :t |

t column: #index; column: #details.

t transmit to: #index; andShow: [:a | a list].

t transmit from: #index; to: #details; andShowIfNone: [:an | 

an accumulator show: [ :a | a text; title: #asString ] ]];

openOn: (1 to: 100)

An accumulator is typically used together with andShowIfNone: because you want them to accumulate entities as you passed them to it.

A similar approach should probably be applied to working with Roassal as well. Would you like to give it a try?

Cheers,

Doru

On Wed, Dec 18, 2013 at 5:50 PM, Ben Coman <btc@openinworld.com> wrote:

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

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev