28 Nov
2011
28 Nov
'11
7:38 p.m.
On Mon, Nov 28, 2011 at 1:56 PM, Alexandre Bergel
<alexandre.bergel(a)me.com>wrote;wrote:
great!
Pretty neat.
Now, we need a nice animation for creating and relayouting the nodes :).
Done.
Update Roassal and try:
ROExample new expandableNodes
What else? What do you want to see in Roassal?
I wonder how to initially show the graph. Just to show the root as a
expandable node would be fine, then the user can navigate the graph.
Now, maybe Mondrian/Roassal allows going further, so I want to imagine the
next step:
The scenario I have in mind is when the user suspects there is an
unexpected reference and wants to discover it. The reason can be that the
file is unusually big, or that the user discovered in the file an instance
of a class that shouldn't be there.
So it would be useful to ask the tool things like:
- paint / iterate the nodes such [:object | object class == UnexpectedClass]
- suggest me a "bottleneck" edge
- show me the shape of the whole graph and I could discover what is wrong
at a glance
What do you think?
thanks,
Martin
Cheers,
Alexandre
--
www.tudorgirba.com
"The coherence of a trip is given by the clearness of the goal."
_______________________________________________
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
On 24 Nov 2011, at 20:16, Alexandre Bergel wrote:
> Cool!
>
> Here is a new version of your script:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> | view initialNodes |
> view := ROView new.
> initialNodes := (ROLabelElement spritesFor: (Array with: Integer))
asOrderedCollection.
> initialNodes do: [:n |
> n + ROLabel.
> n @ (ROExpandChildrenOnClick newCalculatingChildrenWith:
[:aClass
| aClass subclasses])].
> view addAll: initialNodes.
> ROTreeLayout on: initialNodes.
> view @RODraggable @ RODraggableWithVelocity.
> view open
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> I also fixed a few things in your class:
> <ROExpandChildrenOnClick.st>
>
> Let me know how it goes.
>
> Cheers,
> Alexandre
>
>
> On 24 Nov 2011, at 15:48, Martin Dias wrote:
>
>> I downloaded Roassal, I like it!
>>
>> Modifying an example, I obtained something like an expandable tree,
but I
don't know how to re-layout after click. Could you help me?
>>
>> I paste the script and I attach a class (which is needed).
>>
>> | view initialNodes |
>> view := ROView new.
>> initialNodes := (ROElement spritesFor: (Array with: Integer))
asOrderedCollection.
>> initialNodes do: [:n |
>> n + ROLabel.
>> n @ (ROExpandChildrenOnClick newCalculatingChildrenWith:
[:aClass | aClass subclasses])].
>> view addAll: initialNodes.
>> ROTreeLayout on: initialNodes.
>> view open
>>
>> Thanks!
>> Martín
>>
>>
>> On Tue, Nov 15, 2011 at 9:41 AM, Alexandre Bergel <
alexandre.bergel(a)me.com> wrote:
>>> 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
>>>>
>>>>
>>>>
>>>>> On 14 Nov 2011, at 17:30, Alexandre Bergel wrote:
>>>>>
>>>>>> 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
>>>>
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> 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
>>>
>>> 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
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> 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
>>
>>
<ROExpandChildrenOnClick.st>_______________________________________________
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