2014-11-07 12:28 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
===
"the three following lines are ok for me"
v := RTView new.
shape := RTEllipse new size: 20; color: Color lightBlue.
shape := shape + RTLabel.

"ok, we are transforming a collection of objects into roassal elements"
es := shape elementsOn: (1 to: 20).
"and we add them to the view."
v addAll: es.
"my point here is that the visualization is not directly correlated to the objects. Objects are transformed. It means that if I add a new object, I also should add a new element and add it in the visualization. This is not trivial to understand. Why is it not done lazily ?”

First, this situation is not common. Visualizing changes of a data set while these changes are occurring has not been a pressing case study Roassal should address. Until you have sent your email :-)

Ok, it is interesting to have a new test case :)
Let's do it.
 

Let’s go it iteratively. You said : "It means that if I add a new object”
How do you want to add it? What about the following scenario:

-=-=-=-=-=-=-=-=-=-=
myCollection := OrderedCollection new.
v := RTView new.
v addAll: (RTEllipse elementsOn: myCollection).

myCollection add: 1; add: 2; add: 3.
v
-=-=-=-=-=-=-=-=-=-=

If you execute this script, the view will be empty, since elements are created before the collection is filled. However, I have the impression this is what you wish to have? 

Yes, because when I am using elementsOn: a collection, my idea is that it should take care about the collection, not the items of the collection. 
I saw the source code, and it is not easy to manage.
But in my case, I tried to understand, and extend the RTAnimation that you propose to me, but it is not trivial.

It can work with RTAnimation and adding that inside it. That is what I did, but it makes the code unreadable because I add objects, then transform them, then add them to RT with elementsOn:.

My question here is: can we do it smarter. You could probably propose me a better way to do that.
 
 

"following lines create edges, it is ok"
RTEdgeBuilder new
view: v;
objects: (1 to: 20) from: [ :i | i // 2 ].

"We are applying a layout to a group of elements, not to a view. It means that all the expected behaviors are on the group of elements"
RTTreeLayout on: es.

"Here is strange. Why RTDraggable is applied to es and not to a shape ?"
es @ RTDraggable.
v

Shapes are solely about the visual aspect of each individual elements. 

Does there anywhere a comment to say for each RT class on what they can be applied ?
 

===
You know what I mean. Roassal has multiple key elements: objects, elements, view. And I do not see the interactions and builder.

I would like to know what is applied to each element.

An element is a wrapper to an external provided object (e.g., a number, a file, your object).
To an element, you can add a shape (composed or not), and interaction. Elements are added in a view. 
Builders are at a higher level. Builders offer API to build more sophisticated elements, shapes, interactions and layouts. But it all boils down into shapes and interaction added to elements, and elements added to a view.

Ok, I begin to understand. I will try to write something about my understanding and the work I am doing. It can help.
 

I am updating the Roassal chapter with these information. 

Thank you a lot.

Cheers,
Jannik
 

Cheers,
Alexandre


Cheers,
Jannik


2014-11-07 10:48 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
Hi Jannik,

You are raising an excellent point! Designing a documentation that find the right balance between what roassal offers, how people want to use it, and considering the previous knowledge people may have is hardly difficult.

Let me try:
  - There are three sources of documentation for Roassal2: the http://agilevisualization.com book, examples contains in Roassal2, and this mailing list. Chapters about Mondrian, Roassal1 are more than obsolete by now. 

 - You may want to try to work with the core of Roassal. Just focus on the Roassal2-Core then. Just look at the ‘Roassal Example’ in the example browser. Play a bit with it. Once you understand the basic functionalities of Roassal, you can read more about the builders (what I think you are referring to with ‘scripts’). Chapter II.1 in Agile Visualization.

An advice: do no try to build any complex Visualization in Roassal without having read the builder infrastructure. 

Cheers,
Alexandre

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Nov 7, 2014, at 10:25 AM, jannik laval <jannik.laval@gmail.com> wrote:

Hi Alex,

I am trying to use Roassal2. We can do amazing things with it. It is a powerful tool.

But, it lakes of documentation. I mean, there are lots of examples and we can reuse them.
My problem is that I cannot create something from scratch, just because I do not understand the workflow.

You know, I used Glamour and Mondrian, where the workflow were clear. In Roassal2, I am playing with blocks without understanding and without any idea what can be the result before executing it.

My problem is not about language or DSL or API.
My question is: do you have a document that explain how to think a Roassal script ?
It seems that to make something we can do it by multiple way. I just need one way to understand the workflow or creating visualization.

Thank you for your help.

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


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




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


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




--