17 Oct
2012
17 Oct
'12
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."