[Moose-dev] Re: Mondrian expandable nodes

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. Thanks! 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. 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. 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. 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 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 anything else you would like to see? Easel and to see AspectMaps. proof script using blocks for recursion... look: wrote: parent graph, not to the inner graph of a selected node. to a tree morph widget (when you expand a node, the whole tree becomes larger). do an experiment: to use Mondrian to visualize the graph that is being serialized with Fuel. drawing some expandable nodes (+). Do you understand what I mean? Is that possible? cannot be done." -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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