15 Nov
2011
15 Nov
'11
1:41 p.m.
I fail to see what these principles are :). Mondrian
is nothing but a very simple graph model with a builder api and some rendering logic.
zOrder is just a smart way of drawing edges such that you can see them properly even in
the case of nested graphs. But, the model does not have to be static.
Although quite effective visually, the zOrder gives an ordering that may be different from
the one specified by the user.
You could have:
view node: 'A' forIt: [ view node: 'B' ]
But the ordering of drawing A and B is driven by the zOrder. The elements to displayed are
cached in the MONode. However, the lookup when you define an edge itself follows the node
nesting.
I agree with you that the model that does not have to be static, but over the year we have
put a great deal of effort in making Mondrian fast. Now, we are trying to make it dynamic
in addition. This is a non-trivial piece of work.
Also, I have the intuition that we need a dedicated DSL to define the kind of
visualization Martin is looking for.
I took a quick look at Roassal. It looks quite
interesting.
Thanks!
I have some questions/remarks:
- What is the performance for large views when compared with Mondrian?
I haven't addressed the need for performance. One cool thing about Roassal, is that I
do not rely on the Morph scrollbar. This gives more control about what exactly is
displayed. Also, I have flying cameras, which is neat.
- It is at a lower level of abstraction than Mondrian,
but higher than actual rendering. The first thing I thought of when looking at it was that
perhaps it would be interesting to have it as a backend for Mondrian. Like this we can
potentially have the best of both worlds and we can reuse the engineering effort. And then
I saw ROMondrianViewBuilder which is a good start :).
Ideally, I would like Roassal to be a low level for Mondrian. This is indeed what I tried
with ROMondrianViewBuilder as you can see. I guess that for Martin problem, we need
something like ROHierarchicalGraphViewBuilder.
- I like the decoration. This is what we had in
Mondrian, but that got lost in translation.
Yes!
I also would like to have decorators to manage caches. Having caches within MOGraphElement
and its subclasses complexify the whole thing.
- The rendering logic is tightly coupled with Morphic.
It does not have to be, right?
Is not really tight to Morphic.
Classes such as ROLine, ROBox, ROCircle do not directly talk to a form, but to a ROCanvas
instead. I will probably add ROFormCanvas, ROHTML5Canvas in the near future
- I did not see how the decision of drawing edge
appears to be. For example, in the mondrian2 you have the edges drawn on top of the nodes.
But, I am not sure if this is because of the declaration order of because of something
else.
The view had an ordered collection of elements, which is sequentially displayed.
The strategy of displaying edges should not be hardcoded in the ROView.
Consider the script:
-=-=-=-=-=-=-=-=-=-=-=-=
| view |
view := ROMondrianViewBuilder new.
view nodes: Collection withAllSubclasses.
view shape line.
view edgesFrom: #superclass.
view treeLayout.
view open
-=-=-=-=-=-=-=-=-=-=-=-=
We could have
-=-=-=-=-=-=-=-=-=-=-=-=
...
view treeLayout.
view moveEdgesToTheBack.
view open
-=-=-=-=-=-=-=-=-=-=-=-=
Maybe... Not really elegant. But the order should not be hardcoded
Alexandre
Cheers,
Doru
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre
--
www.tudorgirba.com
Innovation comes in least expected form.
That is, if it is expected, it already happened.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev On 14 Nov 2011, at 17:30, Alexandre Bergel
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 Martin, are you happy with what Mondrian offers
currently? Is there anything else you would like to see?
Alexandre
On 8 Nov 2011, at 15:50, Martin Dias wrote:
> Johan and Alexandre: Thank you, was funny to play with Mondrian Easel and to see
AspectMaps.
> Doru: You was right, I had in mind something like a tree. I made a proof script using
blocks for recursion... look:
>
> | blockForClass blockForExpandable blockForLeaf |
> blockForClass := [:aClass |
> blockForLeaf value: aClass.
> aClass subclasses do: [:aSubclass |
> (aSubclass subclasses isEmpty
> ifTrue: [blockForLeaf]
> ifFalse: [blockForExpandable])
> value: aSubclass ] ].
> blockForLeaf := [:aClass |
> view shape label text: #name.
> view node: aClass.
> view edgesFrom: #superclass.
> view horizontalTreeLayout ].
> blockForExpandable := [:aClass |
> view interaction
> whenClickingUpdateNode: [:x | blockForClass value: x ]
> withLayoutUpdate: true.
> view shape rectangle
> dashedBorder;
> size: 10;
> borderColor: Color lightGray.
> view node: aClass.
> view edgesFrom: #superclass.
> view horizontalTreeLayout ].
> blockForClass value: Collection.
>
>
>
>
>
> On Tue, Nov 8, 2011 at 4:16 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Hi,
>
> I think Martin was asking for a script that would add nodes to the parent graph, not
to the inner graph of a selected node.
>
> The idea is to have an expandable graph that would behave similarly to a tree morph
widget (when you expand a node, the whole tree becomes larger).
>
> Cheers,
> Doru
>
>
>
> On 8 Nov 2011, at 04:28, Alexandre Bergel wrote:
>
>>> During Smalltalks conference, we started with Mariano and Doru to do an
experiment: to use Mondrian to visualize the graph that is being serialized with Fuel.
>>
>> Cool!
>>
>>> 1) Is it fine how I installed Mondrian?
>>>
>>> Gofer it
>>> squeaksource: 'Mondrian';
>>> package: 'ConfigurationOfMondrian';
>>> load.
>>> (ConfigurationOfMondrian project latestVersion) load.
>>
>> Yes.
>>
>>> 2) For large graphs, I would like to show them lazily, maybe drawing some
expandable nodes (+). Do you understand what I mean? Is that possible?
>>
>> Try this in an easel:
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> view shape rectangle size: 20.
>> view interaction action: #inspect.
>> view interaction
>> whenEnteringUpdateNode: [:node |
>> view interaction forwarder.
>> view nodes: (Set allSubclasses).
>> view interaction forwarder.
>> view edgesFrom: #superclass..
>> view treeLayout
>> ]
>> whenLeavingUpdateNode: [:node | ]
>> withLayoutUpdate: true.
>> view nodes: (1 to: 3)
>> -=-=-=-=-=-=-=-=-=-=-=-=
>>
>> Cheers,
>> 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
>
> "Not knowing how to do something is not an argument for how it cannot be
done."
>
>
> _______________________________________________
> 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
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
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