[Moose-dev] Re: Mondrian expandable nodes

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