[Moose-dev] Re: Mondrian expandable nodes

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 &lt;alexandre.bergel(a)me.com&gt; 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 &lt;tudor(a)tudorgirba.com&gt; 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 -- 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