11 Oct
2012
11 Oct
'12
8:46 a.m.
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"
11 Oct
11 Oct
9:49 a.m.
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 <tudor(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:37 p.m.
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 <tudor(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12 Oct
12 Oct
3:24 p.m.
Hi,
On Thu, Oct 11, 2012 at 1:37 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;wrote:
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(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
14 Oct
14 Oct
1:42 a.m.
- 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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:16 a.m.
Hi,
On Sun, Oct 14, 2012 at 1:42 AM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;wrote:
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
--
www.tudorgirba.com
"Every thing has its own flow"
- 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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:07 p.m.
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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:49 p.m.
Hi,
On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
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.
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...
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
- 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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
15 Oct
15 Oct
3:18 p.m.
Well spotted.
Version 1.165 of Roassal is now consistent.
Cheers,
Alexandre
On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi,
On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
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.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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...
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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev - 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 <tudor(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:05 p.m.
In which way?
Cheers,
Doru
On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;wrote:
Well spotted.
Version 1.165 of Roassal is now consistent.
Cheers,
Alexandre
On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com>
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.
a
parallel hierarchy for shape builders to make them talk with the model.
It can be done, but the design should be consistent.
Within the builder it can be otherwise...
If all shapes work consistently with the element, we would have to build
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 <tudor(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:22 p.m.
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 <tudor(a)tudorgirba.com> wrote:
In which way?
Cheers,
Doru
On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Well spotted.
Version 1.165 of Roassal is now consistent.
Cheers,
Alexandre
On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
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.
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
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...
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
--
www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem
understanding."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> - 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 <tudor(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:34 p.m.
Great.
This piece of documentation should go in ROShape.
Doru
On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
In which way?
Cheers,
Doru
On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <
alexandre.bergel(a)me.com>
wrote:
Well spotted.
Version 1.165 of Roassal is now consistent.
Cheers,
Alexandre
On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com>
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 <tudor(a)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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)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(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
6:21 p.m.
This piece of documentation should go in ROShape.
Done
Alexandre
Doru
On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> 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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
In which way?
Cheers,
Doru
On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Well spotted.
Version 1.165 of Roassal is now consistent.
Cheers,
Alexandre
On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
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.
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 <tudor(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)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(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:36 p.m.
Great! I like it now :)
Doru
On 15 Oct 2012, at 18:21, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
www.tudorgirba.com
"Some battles are better lost than fought."
This piece of
documentation should go in ROShape.
Done
Alexandre
Doru
On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> 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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev In which way?
Cheers,
Doru
On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Well spotted.
Version 1.165 of Roassal is now consistent.
Cheers,
Alexandre
On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi,
On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com> 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 <tudor(a)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(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> 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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
17 Oct
17 Oct
12:06 p.m.
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 <tudor(a)tudorgirba.com> wrote:
Great! I like it now :)
Doru
On 15 Oct 2012, at 18:21, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
alexandre.bergel(a)me.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
This
piece of documentation should go in ROShape.
Done
Alexandre
>
> Doru
>
>
> On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel < > 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
<tudor(a)tudorgirba.com> wrote:
>
>>> In which way?
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <
alexandre.bergel(a)me.com> wrote:
>> Well spotted.
>> Version 1.165 of Roassal is now consistent.
>>
>> Cheers,
>> Alexandre
>>
>> On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
>>
>>> Hi,
>>>
>>> On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com>
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
<tudor(a)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(a)iam.unibe.ch
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)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(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> 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
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>>
_______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)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(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Some battles are better lost than fought."
7:11 p.m.
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 <tudor(a)tudorgirba.com> 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 <tudor(a)tudorgirba.com> wrote:
Great! I like it now :)
Doru
On 15 Oct 2012, at 18:21, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
--
www.tudorgirba.com
"Some battles are better lost than fought."
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
This
piece of documentation should go in ROShape.
Done
Alexandre
Doru
On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> 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 <tudor(a)tudorgirba.com> wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev In which way?
Cheers,
Doru
On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Well spotted.
Version 1.165 of Roassal is now consistent.
Cheers,
Alexandre
On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com> 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 <tudor(a)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(a)iam.unibe.ch
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)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(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)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(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> 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
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:08 p.m.
Excellent!
Doru
On Wed, Oct 17, 2012 at 7:11 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;wrote:
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 <tudor(a)tudorgirba.com> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
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 <tudor(a)tudorgirba.com>
wrote:
Great! I like it now :)
Doru
On 15 Oct 2012, at 18:21, Alexandre Bergel <alexandre.bergel(a)me.com>
wrote:
>> This piece of documentation should go in ROShape.
>
> Done
>
> Alexandre
>
>
>>
>> Doru
>>
>>
>> On Mon, Oct 15, 2012 at 4:22 PM, Alexandre Bergel <
alexandre.bergel(a)me.com> 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 <tudor(a)tudorgirba.com>
wrote:
>>
> >>> In which way?
> >>>
> >>> Cheers,
> >>> Doru
> >>>
> >>>
> >>>
> >>> On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <
alexandre.bergel(a)me.com> wrote:
>>> Well spotted.
>>> Version 1.165 of Roassal is now consistent.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>> On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
>>>
>>>> Hi,
>>>>
>>>> On 14 Oct 2012, at 16:07, Alexandre Bergel
<alexandre.bergel(a)me.com>
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
<tudor(a)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(a)iam.unibe.ch
>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>>
>>>>>>> --
>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)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(a)iam.unibe.ch
>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>>
>>>>>> --
>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>>> Alexandre Bergel http://www.bergel.eu
>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)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(a)iam.unibe.ch
>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>>
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)iam.unibe.ch
>>>>> 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
> >>>> Moose-dev(a)iam.unibe.ch
> >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>>
> >>> --
> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >>> Alexandre Bergel http://www.bergel.eu
> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Moose-dev mailing list
> >>> Moose-dev(a)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(a)iam.unibe.ch
> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
> >> --
> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> >> Alexandre Bergel http://www.bergel.eu
> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> Moose-dev(a)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(a)iam.unibe.ch
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> > _______________________________________________
> > Moose-dev mailing list
> > Moose-dev(a)iam.unibe.ch
> > 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
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4226
days inactive
4232
days old
16 comments
3 participants
participants (3)
-
Alexandre Bergel -
H. Hirzel -
Tudor Girba