Hi,
On Thu, Oct 11, 2012 at 1:37 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
This is an interesting analyze. You've said "it would be cool to look for solutions that marry both (1) the transformation engine level that speaks mostly the "language" of the original objects, and (2) the graphical engine that offers basic blocks for visual manipulation."
The builder is exactly for this purpose. Is there something that is missing in the builder, beside being refactored out?
I know that this is the intention and this is great. But: - The builder should be about transformation as much as possible. For example, right now the variable passed in the item:action: is the Element not the model. This was a recent choice and it had its reasons. It's just that not having a clear distinction of what the goal of each abstraction is, we will get to less clear results. - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. - And perhaps we have to go beyond the current builder. For example, EyeSee is an example of another API and model that could probably be implemented on top of Roassal.
Cheers, Doru
Cheers, Alexandre
On Oct 11, 2012, at 3:46 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
There were several posts that intrigued me lately related to the difference between Mondrian and Roassal, and I did not know exactly why. Now, I think the reason stems from the conceptual difference between the two. So, here I go :)
- Roassal is a basic engine that provides a DOM-like graph object
model. Its main goal is to enable one to build and manipulate visual objects.
- Mondrian is a high level transformation engine. Its main goal is to
enable one to transform an arbitrary subject model into a graph visualization.
Of course, Mondrian had a basic engine, too, inside, but it was not as flexible as Roassal (especially in the animation part). However, the main point of Mondrian was really to support the transformation.
It is for this reason that all blocks in the Mondrian API take the subject model as an input. The target is the developer that knows his model and almost nothing about Mondrian (except for the simple transformation predicates). This was a conscious decision, not a mistake. It is clear that you miss flexibility (e.g., you cannot manipulate the node within an action block), but you gain simplicity for basic actions.
Another choice in Mondrian was to focus on the graph model. It is again clear that this decision excluded some classes of visualizations, and as a result several visualizations misused the high-level transformation engine for low level object placing. An example of this is the DSM. It is precisely in this area (and of course others that were not charted yet) that Roassal can play a very important role.
I think both points of view are important, and it would be cool to look for solutions that marry both (1) the transformation engine level that speaks mostly the "language" of the original objects, and (2) the graphical engine that offers basic blocks for visual manipulation.
Cheers, Doru
-- 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
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev