Mondrian vs Roassal: a conceptual comparison
Locked
Mondrian vs Roassal: a conceptual comparison
 
|
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
Thank you, Doru, for this insightful explanations. I was always
wondering what the relationship between Mondrian and Roassal is. So it is not that Roassal is just the successor of Mondrian. Both have their fields of applications in their own right.... --Hannes On 10/11/12, Tudor Girba <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
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? Cheers, Alexandre On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
Hi,
On Thu, Oct 11, 2012 at 1:37 PM, Alexandre Bergel <[hidden email]> wrote: This is an interesting analyze. 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, "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> - 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.
I am not sure there are many client of it and this is easy to fix. Maybe having an #item:actionOnNode: ? > - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. Yes > - 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. That would be cool. Some users of Roassal have expressed such a need... Alexandre > > Cheers, > Doru > > > > Cheers, > Alexandre > > > On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
Hi,
All visualizations in Moose would use this to offer the default mooseMenu. Anyway, the point is that if we want to have clear future design decisions, the conceptual separation would be important.
For example, take the text block of a label: textFor: aROElement | v | v := (text roValue: aROElement). ... If the separation would be clear for everyone the roValue: would be evaluated against the model. Cheers, Doru
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> For example, take the text block of a label:
> > textFor: aROElement > | v | > v := (text roValue: aROElement). > ... > > If the separation would be clear for everyone the roValue: would be evaluated against the model. We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. Within the builder it can be otherwise... Alexandre > > > > - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. > > Yes > > > - 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. > > That would be cool. > Some users of Roassal have expressed such a need... > > Alexandre > > > > > Cheers, > > Doru > > > > > > > > Cheers, > > Alexandre > > > > > > On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 > > > [hidden email] > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
Hi,
On 14 Oct 2012, at 16:07, Alexandre Bergel <[hidden email]> wrote: >> For example, take the text block of a label: >> >> textFor: aROElement >> | v | >> v := (text roValue: aROElement). >> ... >> >> If the separation would be clear for everyone the roValue: would be evaluated against the model. > > We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. The problem is that right now Roassal is not consistent. Either all transformation methods in shapes talk to the element, or they all talk to the model. Right now, we have 4 methods talking to the model and 3 talking to the element. Evaluate this to check: methodsThatCallModel := OrderedCollection new. methodsThatCallElement := OrderedCollection new. ROShape withAllSubclasses flatCollect: [:cls | | forMethods | forMethods := cls methods select: [:each | each selector endsWith: 'For:']. forMethods do: [:method | method parseTree allChildren do: [:node | (node isMessage and: [ node selector = #roValue: ]) ifTrue: [ (node children noneSatisfy: [:childNode | childNode isMessage ]) ifTrue: [methodsThatCallModel add: method] ifFalse: [methodsThatCallElement add: method] ] ] ] ]. methodsThatCallModel explore. methodsThatCallElement explore. > Within the builder it can be otherwise... If all shapes work consistently with the element, we would have to build a parallel hierarchy for shape builders to make them talk with the model. It can be done, but the design should be consistent. Cheers, Doru > Alexandre > > > >> >> >>> - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. >> >> Yes >> >>> - 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. >> >> That would be cool. >> Some users of Roassal have expressed such a need... >> >> Alexandre >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> Cheers, >>> Alexandre >>> >>> >>> On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Well spotted.
Version 1.165 of Roassal is now consistent. Cheers, Alexandre On Oct 14, 2012, at 4:49 PM, Tudor Girba <[hidden email]> wrote: > Hi, > > On 14 Oct 2012, at 16:07, Alexandre Bergel <[hidden email]> wrote: > >>> For example, take the text block of a label: >>> >>> textFor: aROElement >>> | v | >>> v := (text roValue: aROElement). >>> ... >>> >>> If the separation would be clear for everyone the roValue: would be evaluated against the model. >> >> We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. > > The problem is that right now Roassal is not consistent. Either all transformation methods in shapes talk to the element, or they all talk to the model. Right now, we have 4 methods talking to the model and 3 talking to the element. > > Evaluate this to check: > methodsThatCallModel := OrderedCollection new. > methodsThatCallElement := OrderedCollection new. > ROShape withAllSubclasses flatCollect: [:cls | > | forMethods | > forMethods := cls methods select: [:each | each selector endsWith: 'For:']. > forMethods do: [:method | > method parseTree allChildren do: [:node | > (node isMessage and: [ node selector = #roValue: ]) > ifTrue: [ > (node children noneSatisfy: [:childNode | childNode isMessage ]) > ifTrue: [methodsThatCallModel add: method] > ifFalse: [methodsThatCallElement add: method] > ] > ] > ] > ]. > methodsThatCallModel explore. > methodsThatCallElement explore. > > >> Within the builder it can be otherwise... > > If all shapes work consistently with the element, we would have to build a parallel hierarchy for shape builders to make them talk with the model. It can be done, but the design should be consistent. > > Cheers, > Doru > > >> Alexandre >> >> >> >>> >>> >>>> - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. >>> >>> Yes >>> >>>> - 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. >>> >>> That would be cool. >>> Some users of Roassal have expressed such a need... >>> >>> Alexandre >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
In which way?
Cheers, Doru
On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <[hidden email]> wrote: Well spotted. "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
All the accessors in Mondrian's builder operates on the model.
However, outside the builder, shapes accepts roassal elements. For example: -=-=-=-=-=-=-=-=-=-=-=-= testIfFillColor | nodes | view shape rectangle if: #odd fillColor: [ :model | model + 1]; if: #even fillColor: [ :model | model + 10]. nodes := view nodes: #(2 3 4 5 6). self assert: (nodes collect: [ :n | (n getShape: ROBox) colorFor: n]) = #(12 4 14 6 16) -=-=-=-=-=-=-=-=-=-=-=-= This piece of code works only in the test since a number is not a color. But it illustrates the point. Then fillColor: is defined as: -=-=-=-=-=-=-=-=-=-=-=-= ROMondrianBuilder>>fillColor: aBlockOrSymbol "aBlockOrSymbol expect to be evaluated against the model. It may either be a symbol or a one-arg block" shape color: [ :element | aBlockOrSymbol roValue: element model ] -=-=-=-=-=-=-=-=-=-=-=-= Something is left ugly, that I cannot easily remove: -=-=-=-=-=-=-=-=-=-=-=-= ROMondrianBuilder>>if: conditionBlock fillColor: colorBlock "If conditionBlock is evaluated at true, then colorBlock is used to set the color of the node. Both conditionBlock and colorBlock are evaluated with the model value of the node." | oldBlockOrValue | oldBlockOrValue := self fillColor ifNil: [ self defaultFillColor ]. ^self fillColor: [ :aModel | (conditionBlock roValue: aModel) ifTrue: [ colorBlock roValue: aModel ] ifFalse: [ "Having to create a new element is rather ugly. Ideally, the oldBlockOrValue has to be 'unwrapped' for the translation" oldBlockOrValue roValue: (ROElement on: aModel) ]]. -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On Oct 15, 2012, at 11:05 AM, Tudor Girba <[hidden email]> wrote: > In which way? > > Cheers, > Doru > > > > On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <[hidden email]> wrote: > Well spotted. > Version 1.165 of Roassal is now consistent. > > Cheers, > Alexandre > > On Oct 14, 2012, at 4:49 PM, Tudor Girba <[hidden email]> wrote: > > > Hi, > > > > On 14 Oct 2012, at 16:07, Alexandre Bergel <[hidden email]> wrote: > > > >>> For example, take the text block of a label: > >>> > >>> textFor: aROElement > >>> | v | > >>> v := (text roValue: aROElement). > >>> ... > >>> > >>> If the separation would be clear for everyone the roValue: would be evaluated against the model. > >> > >> We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. > > > > The problem is that right now Roassal is not consistent. Either all transformation methods in shapes talk to the element, or they all talk to the model. Right now, we have 4 methods talking to the model and 3 talking to the element. > > > > Evaluate this to check: > > methodsThatCallModel := OrderedCollection new. > > methodsThatCallElement := OrderedCollection new. > > ROShape withAllSubclasses flatCollect: [:cls | > > | forMethods | > > forMethods := cls methods select: [:each | each selector endsWith: 'For:']. > > forMethods do: [:method | > > method parseTree allChildren do: [:node | > > (node isMessage and: [ node selector = #roValue: ]) > > ifTrue: [ > > (node children noneSatisfy: [:childNode | childNode isMessage ]) > > ifTrue: [methodsThatCallModel add: method] > > ifFalse: [methodsThatCallElement add: method] > > ] > > ] > > ] > > ]. > > methodsThatCallModel explore. > > methodsThatCallElement explore. > > > > > >> Within the builder it can be otherwise... > > > > If all shapes work consistently with the element, we would have to build a parallel hierarchy for shape builders to make them talk with the model. It can be done, but the design should be consistent. > > > > Cheers, > > Doru > > > > > >> Alexandre > >> > >> > >> > >>> > >>> > >>>> - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. > >>> > >>> Yes > >>> > >>>> - 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. > >>> > >>> That would be cool. > >>> Some users of Roassal have expressed such a need... > >>> > >>> Alexandre > >>> > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>> > >>>> Cheers, > >>>> Alexandre > >>>> > >>>> > >>>> On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 > >>>>> [hidden email] > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>>> -- > >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>> Alexandre Bergel http://www.bergel.eu > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> [hidden email] > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>>> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Every thing has its own flow" > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> [hidden email] > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > www.tudorgirba.com > > > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
Great.
This piece of documentation should go in ROShape. Doru On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <[hidden email]> wrote: All the accessors in Mondrian's builder operates on the model. "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> This piece of documentation should go in ROShape.
Done Alexandre > > Doru > > > On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <[hidden email]> wrote: > All the accessors in Mondrian's builder operates on the model. > However, outside the builder, shapes accepts roassal elements. > > For example: > -=-=-=-=-=-=-=-=-=-=-=-= > testIfFillColor > > | nodes | > view shape rectangle > if: #odd fillColor: [ :model | model + 1]; > if: #even fillColor: [ :model | model + 10]. > nodes := view nodes: #(2 3 4 5 6). > > self assert: (nodes collect: [ :n | (n getShape: ROBox) colorFor: n]) = #(12 4 14 6 16) > -=-=-=-=-=-=-=-=-=-=-=-= > > This piece of code works only in the test since a number is not a color. But it illustrates the point. > > Then fillColor: is defined as: > -=-=-=-=-=-=-=-=-=-=-=-= > ROMondrianBuilder>>fillColor: aBlockOrSymbol > "aBlockOrSymbol expect to be evaluated against the model. It may either be a symbol or a one-arg block" > > shape color: [ :element | aBlockOrSymbol roValue: element model ] > -=-=-=-=-=-=-=-=-=-=-=-= > > Something is left ugly, that I cannot easily remove: > > > -=-=-=-=-=-=-=-=-=-=-=-= > ROMondrianBuilder>>if: conditionBlock fillColor: colorBlock > "If conditionBlock is evaluated at true, then colorBlock is used to set the color of the node. Both conditionBlock and colorBlock are evaluated with the model value of the node." > > | oldBlockOrValue | > oldBlockOrValue := self fillColor ifNil: [ self defaultFillColor ]. > ^self fillColor: [ :aModel | (conditionBlock roValue: aModel) > ifTrue: [ colorBlock roValue: aModel ] > ifFalse: [ > "Having to create a new element is rather ugly. > Ideally, the oldBlockOrValue has to be 'unwrapped' for the translation" > oldBlockOrValue roValue: (ROElement on: aModel) ]]. > -=-=-=-=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > > > > > On Oct 15, 2012, at 11:05 AM, Tudor Girba <[hidden email]> wrote: > > > In which way? > > > > Cheers, > > Doru > > > > > > > > On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <[hidden email]> wrote: > > Well spotted. > > Version 1.165 of Roassal is now consistent. > > > > Cheers, > > Alexandre > > > > On Oct 14, 2012, at 4:49 PM, Tudor Girba <[hidden email]> wrote: > > > > > Hi, > > > > > > On 14 Oct 2012, at 16:07, Alexandre Bergel <[hidden email]> wrote: > > > > > >>> For example, take the text block of a label: > > >>> > > >>> textFor: aROElement > > >>> | v | > > >>> v := (text roValue: aROElement). > > >>> ... > > >>> > > >>> If the separation would be clear for everyone the roValue: would be evaluated against the model. > > >> > > >> We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. > > > > > > The problem is that right now Roassal is not consistent. Either all transformation methods in shapes talk to the element, or they all talk to the model. Right now, we have 4 methods talking to the model and 3 talking to the element. > > > > > > Evaluate this to check: > > > methodsThatCallModel := OrderedCollection new. > > > methodsThatCallElement := OrderedCollection new. > > > ROShape withAllSubclasses flatCollect: [:cls | > > > | forMethods | > > > forMethods := cls methods select: [:each | each selector endsWith: 'For:']. > > > forMethods do: [:method | > > > method parseTree allChildren do: [:node | > > > (node isMessage and: [ node selector = #roValue: ]) > > > ifTrue: [ > > > (node children noneSatisfy: [:childNode | childNode isMessage ]) > > > ifTrue: [methodsThatCallModel add: method] > > > ifFalse: [methodsThatCallElement add: method] > > > ] > > > ] > > > ] > > > ]. > > > methodsThatCallModel explore. > > > methodsThatCallElement explore. > > > > > > > > >> Within the builder it can be otherwise... > > > > > > If all shapes work consistently with the element, we would have to build a parallel hierarchy for shape builders to make them talk with the model. It can be done, but the design should be consistent. > > > > > > Cheers, > > > Doru > > > > > > > > >> Alexandre > > >> > > >> > > >> > > >>> > > >>> > > >>>> - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. > > >>> > > >>> Yes > > >>> > > >>>> - 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. > > >>> > > >>> That would be cool. > > >>> Some users of Roassal have expressed such a need... > > >>> > > >>> Alexandre > > >>> > > >>>> > > >>>> Cheers, > > >>>> Doru > > >>>> > > >>>> > > >>>> > > >>>> Cheers, > > >>>> Alexandre > > >>>> > > >>>> > > >>>> On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 > > >>>>> [hidden email] > > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >>>> > > >>>> -- > > >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >>>> Alexandre Bergel http://www.bergel.eu > > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Moose-dev mailing list > > >>>> [hidden email] > > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >>>> > > >>>> > > >>>> > > >>>> -- > > >>>> www.tudorgirba.com > > >>>> > > >>>> "Every thing has its own flow" > > >>>> > > >>>> _______________________________________________ > > >>>> Moose-dev mailing list > > >>>> [hidden email] > > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >>> > > >>> -- > > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >>> Alexandre Bergel http://www.bergel.eu > > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Moose-dev mailing list > > >>> [hidden email] > > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >>> > > >>> > > >>> > > >>> -- > > >>> www.tudorgirba.com > > >>> > > >>> "Every thing has its own flow" > > >>> > > >>> _______________________________________________ > > >>> Moose-dev mailing list > > >>> [hidden email] > > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > >> > > >> -- > > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > >> Alexandre Bergel http://www.bergel.eu > > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >> > > >> > > >> > > >> _______________________________________________ > > >> Moose-dev mailing list > > >> [hidden email] > > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > -- > > > www.tudorgirba.com > > > > > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > > > > > > > > > > > _______________________________________________ > > > Moose-dev mailing list > > > [hidden email] > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
Great! I like it now :)
Doru On 15 Oct 2012, at 18:21, Alexandre Bergel <[hidden email]> wrote: >> This piece of documentation should go in ROShape. > > Done > > Alexandre > > >> >> Doru >> >> >> On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <[hidden email]> wrote: >> All the accessors in Mondrian's builder operates on the model. >> However, outside the builder, shapes accepts roassal elements. >> >> For example: >> -=-=-=-=-=-=-=-=-=-=-=-= >> testIfFillColor >> >> | nodes | >> view shape rectangle >> if: #odd fillColor: [ :model | model + 1]; >> if: #even fillColor: [ :model | model + 10]. >> nodes := view nodes: #(2 3 4 5 6). >> >> self assert: (nodes collect: [ :n | (n getShape: ROBox) colorFor: n]) = #(12 4 14 6 16) >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> This piece of code works only in the test since a number is not a color. But it illustrates the point. >> >> Then fillColor: is defined as: >> -=-=-=-=-=-=-=-=-=-=-=-= >> ROMondrianBuilder>>fillColor: aBlockOrSymbol >> "aBlockOrSymbol expect to be evaluated against the model. It may either be a symbol or a one-arg block" >> >> shape color: [ :element | aBlockOrSymbol roValue: element model ] >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Something is left ugly, that I cannot easily remove: >> >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> ROMondrianBuilder>>if: conditionBlock fillColor: colorBlock >> "If conditionBlock is evaluated at true, then colorBlock is used to set the color of the node. Both conditionBlock and colorBlock are evaluated with the model value of the node." >> >> | oldBlockOrValue | >> oldBlockOrValue := self fillColor ifNil: [ self defaultFillColor ]. >> ^self fillColor: [ :aModel | (conditionBlock roValue: aModel) >> ifTrue: [ colorBlock roValue: aModel ] >> ifFalse: [ >> "Having to create a new element is rather ugly. >> Ideally, the oldBlockOrValue has to be 'unwrapped' for the translation" >> oldBlockOrValue roValue: (ROElement on: aModel) ]]. >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> >> >> >> >> On Oct 15, 2012, at 11:05 AM, Tudor Girba <[hidden email]> wrote: >> >>> In which way? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <[hidden email]> wrote: >>> Well spotted. >>> Version 1.165 of Roassal is now consistent. >>> >>> Cheers, >>> Alexandre >>> >>> On Oct 14, 2012, at 4:49 PM, Tudor Girba <[hidden email]> wrote: >>> >>>> Hi, >>>> >>>> On 14 Oct 2012, at 16:07, Alexandre Bergel <[hidden email]> wrote: >>>> >>>>>> For example, take the text block of a label: >>>>>> >>>>>> textFor: aROElement >>>>>> | v | >>>>>> v := (text roValue: aROElement). >>>>>> ... >>>>>> >>>>>> If the separation would be clear for everyone the roValue: would be evaluated against the model. >>>>> >>>>> We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. >>>> >>>> The problem is that right now Roassal is not consistent. Either all transformation methods in shapes talk to the element, or they all talk to the model. Right now, we have 4 methods talking to the model and 3 talking to the element. >>>> >>>> Evaluate this to check: >>>> methodsThatCallModel := OrderedCollection new. >>>> methodsThatCallElement := OrderedCollection new. >>>> ROShape withAllSubclasses flatCollect: [:cls | >>>> | forMethods | >>>> forMethods := cls methods select: [:each | each selector endsWith: 'For:']. >>>> forMethods do: [:method | >>>> method parseTree allChildren do: [:node | >>>> (node isMessage and: [ node selector = #roValue: ]) >>>> ifTrue: [ >>>> (node children noneSatisfy: [:childNode | childNode isMessage ]) >>>> ifTrue: [methodsThatCallModel add: method] >>>> ifFalse: [methodsThatCallElement add: method] >>>> ] >>>> ] >>>> ] >>>> ]. >>>> methodsThatCallModel explore. >>>> methodsThatCallElement explore. >>>> >>>> >>>>> Within the builder it can be otherwise... >>>> >>>> If all shapes work consistently with the element, we would have to build a parallel hierarchy for shape builders to make them talk with the model. It can be done, but the design should be consistent. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> Alexandre >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. >>>>>> >>>>>> Yes >>>>>> >>>>>>> - 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. >>>>>> >>>>>> That would be cool. >>>>>> Some users of Roassal have expressed such a need... >>>>>> >>>>>> Alexandre >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 >>>>>>>> [hidden email] >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Every thing has its own flow" >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> [hidden email] >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing has its own flow" >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> [hidden email] >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Some battles are better lost than fought." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
There are more related problems.
Here is one:
ROElement>>width: w self extent: (w roValue: self model) @ self height ROElement>>height: h
self extent: self width @ (h roValue: self model) I see two problems here: 1. The width and height are computed by the element when we set the block, rather than be computed in the shape when we need the information.
2. The blocks are evaluated against the model This should be fixed. Cheers, Doru On Mon, Oct 15, 2012 at 8:36 PM, Tudor Girba <[hidden email]> wrote: Great! I like it now :) "Every thing has its own flow" _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I think this issue is now fixed.
We have the following method now: ROElement>>width: w "w could either be a numerical constant, a symbol or a block. It is evaluated against the element" (w = shape width) ifTrue: [ ^ self ]. self announce: ROElementResized. shape width: w ROElement>>height: h "h could either be a numerical constant, a symbol or a block. It is evaluated against the element" (h = shape width) ifTrue: [ ^ self ]. self announce: ROElementResized. shape height: h It is indeed cleaner now. Cheers, Alexandre On Oct 17, 2012, at 7:06 AM, Tudor Girba <[hidden email]> wrote: > There are more related problems. > > Here is one: > ROElement>>width: w > self extent: (w roValue: self model) @ self height > ROElement>>height: h > self extent: self width @ (h roValue: self model) > > I see two problems here: > 1. The width and height are computed by the element when we set the block, rather than be computed in the shape when we need the information. > 2. The blocks are evaluated against the model > > This should be fixed. > > Cheers, > Doru > > > > On Mon, Oct 15, 2012 at 8:36 PM, Tudor Girba <[hidden email]> wrote: > Great! I like it now :) > > Doru > > > On 15 Oct 2012, at 18:21, Alexandre Bergel <[hidden email]> wrote: > > >> This piece of documentation should go in ROShape. > > > > Done > > > > Alexandre > > > > > >> > >> Doru > >> > >> > >> On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <[hidden email]> wrote: > >> All the accessors in Mondrian's builder operates on the model. > >> However, outside the builder, shapes accepts roassal elements. > >> > >> For example: > >> -=-=-=-=-=-=-=-=-=-=-=-= > >> testIfFillColor > >> > >> | nodes | > >> view shape rectangle > >> if: #odd fillColor: [ :model | model + 1]; > >> if: #even fillColor: [ :model | model + 10]. > >> nodes := view nodes: #(2 3 4 5 6). > >> > >> self assert: (nodes collect: [ :n | (n getShape: ROBox) colorFor: n]) = #(12 4 14 6 16) > >> -=-=-=-=-=-=-=-=-=-=-=-= > >> > >> This piece of code works only in the test since a number is not a color. But it illustrates the point. > >> > >> Then fillColor: is defined as: > >> -=-=-=-=-=-=-=-=-=-=-=-= > >> ROMondrianBuilder>>fillColor: aBlockOrSymbol > >> "aBlockOrSymbol expect to be evaluated against the model. It may either be a symbol or a one-arg block" > >> > >> shape color: [ :element | aBlockOrSymbol roValue: element model ] > >> -=-=-=-=-=-=-=-=-=-=-=-= > >> > >> Something is left ugly, that I cannot easily remove: > >> > >> > >> -=-=-=-=-=-=-=-=-=-=-=-= > >> ROMondrianBuilder>>if: conditionBlock fillColor: colorBlock > >> "If conditionBlock is evaluated at true, then colorBlock is used to set the color of the node. Both conditionBlock and colorBlock are evaluated with the model value of the node." > >> > >> | oldBlockOrValue | > >> oldBlockOrValue := self fillColor ifNil: [ self defaultFillColor ]. > >> ^self fillColor: [ :aModel | (conditionBlock roValue: aModel) > >> ifTrue: [ colorBlock roValue: aModel ] > >> ifFalse: [ > >> "Having to create a new element is rather ugly. > >> Ideally, the oldBlockOrValue has to be 'unwrapped' for the translation" > >> oldBlockOrValue roValue: (ROElement on: aModel) ]]. > >> -=-=-=-=-=-=-=-=-=-=-=-= > >> > >> Cheers, > >> Alexandre > >> > >> > >> > >> > >> On Oct 15, 2012, at 11:05 AM, Tudor Girba <[hidden email]> wrote: > >> > >>> In which way? > >>> > >>> Cheers, > >>> Doru > >>> > >>> > >>> > >>> On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <[hidden email]> wrote: > >>> Well spotted. > >>> Version 1.165 of Roassal is now consistent. > >>> > >>> Cheers, > >>> Alexandre > >>> > >>> On Oct 14, 2012, at 4:49 PM, Tudor Girba <[hidden email]> wrote: > >>> > >>>> Hi, > >>>> > >>>> On 14 Oct 2012, at 16:07, Alexandre Bergel <[hidden email]> wrote: > >>>> > >>>>>> For example, take the text block of a label: > >>>>>> > >>>>>> textFor: aROElement > >>>>>> | v | > >>>>>> v := (text roValue: aROElement). > >>>>>> ... > >>>>>> > >>>>>> If the separation would be clear for everyone the roValue: would be evaluated against the model. > >>>>> > >>>>> We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. > >>>> > >>>> The problem is that right now Roassal is not consistent. Either all transformation methods in shapes talk to the element, or they all talk to the model. Right now, we have 4 methods talking to the model and 3 talking to the element. > >>>> > >>>> Evaluate this to check: > >>>> methodsThatCallModel := OrderedCollection new. > >>>> methodsThatCallElement := OrderedCollection new. > >>>> ROShape withAllSubclasses flatCollect: [:cls | > >>>> | forMethods | > >>>> forMethods := cls methods select: [:each | each selector endsWith: 'For:']. > >>>> forMethods do: [:method | > >>>> method parseTree allChildren do: [:node | > >>>> (node isMessage and: [ node selector = #roValue: ]) > >>>> ifTrue: [ > >>>> (node children noneSatisfy: [:childNode | childNode isMessage ]) > >>>> ifTrue: [methodsThatCallModel add: method] > >>>> ifFalse: [methodsThatCallElement add: method] > >>>> ] > >>>> ] > >>>> ] > >>>> ]. > >>>> methodsThatCallModel explore. > >>>> methodsThatCallElement explore. > >>>> > >>>> > >>>>> Within the builder it can be otherwise... > >>>> > >>>> If all shapes work consistently with the element, we would have to build a parallel hierarchy for shape builders to make them talk with the model. It can be done, but the design should be consistent. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>>> Alexandre > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>>> - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. > >>>>>> > >>>>>> Yes > >>>>>> > >>>>>>> - 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. > >>>>>> > >>>>>> That would be cool. > >>>>>> Some users of Roassal have expressed such a need... > >>>>>> > >>>>>> Alexandre > >>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Doru > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Alexandre > >>>>>>> > >>>>>>> > >>>>>>> On Oct 11, 2012, at 3:46 AM, Tudor Girba <[hidden email]> 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 > >>>>>>>> [hidden email] > >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>> > >>>>>>> -- > >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>>>> Alexandre Bergel http://www.bergel.eu > >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Moose-dev mailing list > >>>>>>> [hidden email] > >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> www.tudorgirba.com > >>>>>>> > >>>>>>> "Every thing has its own flow" > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Moose-dev mailing list > >>>>>>> [hidden email] > >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>> > >>>>>> -- > >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>>> Alexandre Bergel http://www.bergel.eu > >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Moose-dev mailing list > >>>>>> [hidden email] > >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> www.tudorgirba.com > >>>>>> > >>>>>> "Every thing has its own flow" > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Moose-dev mailing list > >>>>>> [hidden email] > >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>>> > >>>>> -- > >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>> Alexandre Bergel http://www.bergel.eu > >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> [hidden email] > >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Problem solving efficiency grows with the abstractness level of problem understanding." > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Moose-dev mailing list > >>>> [hidden email] > >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> > >>> > >>> > >>> -- > >>> www.tudorgirba.com > >>> > >>> "Every thing has its own flow" > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Mondrian vs Roassal: a conceptual comparison
|
|
Excellent!
Doru On Wed, Oct 17, 2012 at 7:11 PM, Alexandre Bergel <[hidden email]> wrote: I think this issue is now fixed. "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |