Mondrian expandable nodes

List overview All Threads
Download

newer

older

Issue 645 in moose-technology: we...

Fwd: Pharo + Moose on Windows 7

Martin Dias

7 Nov 2011 7 Nov '11

5:15 p.m.

Hi 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. I want to make two questions about that: 1) Is it fine how I installed Mondrian? Gofer it squeaksource: 'Mondrian'; package: 'ConfigurationOfMondrian'; load. (ConfigurationOfMondrian project latestVersion) load. 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? thanks! Martin

Attachments:

attachment.htm (text/html — 984 bytes)

Show replies by date

Johan Fabry

7 Nov 7 Nov

5:36 p.m.

On 07 Nov 2011, at 13:15, Martin Dias wrote:

...

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?

Yes, you can do something like this: you can dynamically change the contents of a node, like what I do in AspectMaps. It is a bit convoluted, below is the code that works for me. aView forNode: <thenode> do: <a block that draws the new visualisation>. aView root allEdgesDo: #resetCache; applyLayout. aView updateWindow. If you want to see it in action http://pleiad.cl/aspectmaps ;-) (There are screencasts, and even a one-click image for you to try if you want to experiment with the feature). There are some examples in the MOEasel that do similar things, so have a look there as well. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Alexandre Bergel

8 Nov 8 Nov

4:28 a.m.

...

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Tudor Girba

8:16 a.m.

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?

-- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done."

Martin Dias

7:50 p.m.

...

> 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?

Alexandre Bergel

14 Nov 14 Nov

5:30 p.m.

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:

...

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?

-- 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Tudor Girba

7:29 p.m.

It would be great to have the ability of affecting the parent graph of a node, not just the subgraph of a node. Like this we could truly implement the expandable trees. Doru 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:

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?

-- www.tudorgirba.com "Reasonable is what we are accustomed with."

Martin Dias

10:46 p.m.

Hi Alexandre, thanks for asking. The script I posted has an issue: when you expand 2 or 3 nested nodes, some unwanted lines appear. It is possible to live with that, anyway. It could be very useful in serialization because sometimes you start traversing an object and you end up traversing much more objects you wanted. So Mondrian could help to find the problematic objects. On Mon, Nov 14, 2011 at 3:29 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:

...

It would be great to have the ability of affecting the parent graph of a node, not just the subgraph of a node.

...

Like this we could truly implement the expandable trees.

Additionally, it would be nice to express the graph more concisely. I am a newbie in Mondrian so maybe it has not sense what I imagine (following the example with Collection hierarchy): view shape expandableNode childrenNodesWith: [:aNodeToExpand | aExpandableNode subclasses]. view node: Collection. view edgesFrom: #superclass. is it possible to add only the root at first and the rest when nodes expand? Martin

...

Doru 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

11:47 p.m.

...

It could be very useful in serialization because sometimes you start traversing an object and you end up traversing much more objects you wanted. So Mondrian could help to find the problematic objects.

Visualization is cool indeed

...

It would be great to have the ability of affecting the parent graph of a node, not just the subgraph of a node. +1

This goes against some principles in Mondrian (e.g., zOrdering different than object nesting). I tried the following: -=-=-=-=-=-=-=-=-=-=-=-= | n | n := OrderedCollection new. view shape rectangle withText. view interaction on: MOMouseDown do: [ :ann | n add: (MONode on: 'hello'). view root addNode: n last. (MOGridLayout forNodes: n) applyOn: ann node root. view root resetCache; updateWindow ]. view node: 'press me' -=-=-=-=-=-=-=-=-=-=-=-=

...

Humm... Hardly feasible without completely bypassing many things Mondrian was designed for. However, I am currently working on Roassal, a new visualization framework with a strong emphasis on interaction. What you are asking for will be trivial to do. 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:

> 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 "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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Tudor Girba

15 Nov 15 Nov

8:55 a.m.

Hi, On 14 Nov 2011, at 23:47, Alexandre Bergel wrote:

...

Visualization is cool indeed

It would be great to have the ability of affecting the parent graph of a node, not just the subgraph of a node. +1

This goes against some principles in Mondrian (e.g., zOrdering different than object nesting).

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. So, why is adding new nodes against the principles of Mondrian?

...

I tried the following: -=-=-=-=-=-=-=-=-=-=-=-= | n | n := OrderedCollection new. view shape rectangle withText. view interaction on: MOMouseDown do: [ :ann | n add: (MONode on: 'hello'). view root addNode: n last. (MOGridLayout forNodes: n) applyOn: ann node root. view root resetCache; updateWindow ]. view node: 'press me' -=-=-=-=-=-=-=-=-=-=-=-=

It looks like a good start :)

...

I took a quick look at Roassal. It looks quite interesting. I have some questions/remarks: - What is the performance for large views when compared with Mondrian? - 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 :). - I like the decoration. This is what we had in Mondrian, but that got lost in translation. - The rendering logic is tightly coupled with Morphic. It does not have to be, right? - 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. 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

-- www.tudorgirba.com Innovation comes in least expected form. That is, if it is expected, it already happened.

Alexandre Bergel

1:41 p.m.

...

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 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Martin Dias

24 Nov 24 Nov

7:48 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?

- 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

8:16 p.m.

...

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 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

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 <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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Tudor Girba

9:09 p.m.

Pretty neat. Now, we need a nice animation for creating and relayouting the nodes :). Cheers, Doru On 24 Nov 2011, at 20:16, Alexandre Bergel wrote:

...

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 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

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 "The coherence of a trip is given by the clearness of the goal."

Alexandre Bergel

28 Nov 28 Nov

5:56 p.m.

...

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? Cheers, Alexandre

...

On 24 Nov 2011, at 20:16, Alexandre Bergel wrote:

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 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

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

-- 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Martin Dias

7:38 p.m.

On Mon, Nov 28, 2011 at 1:56 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:

...

Pretty neat. Now, we need a nice animation for creating and relayouting the nodes :).

Done. Update Roassal and try: ROExample new expandableNodes

great!

...

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

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

>> >> 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

8:49 p.m.

...

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]

Having some iterators you mean?

...

- suggest me a "bottleneck" edge

An iterator could easily do the thing. I will provide the infrastructure.

...

- show me the shape of the whole graph and I could discover what is wrong at a glance

Yep, this is on my todo list. Having a small portion of the window that shows the whole graph. I will work on this. Alexandre

...

On 24 Nov 2011, at 20:16, Alexandre Bergel 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 _______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Martin Dias

30 Nov 30 Nov

6:10 a.m.

On Mon, Nov 28, 2011 at 4:49 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:

...

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] Having some iterators you mean?

Hmm... I am not sure what do you call iterator. I mean to see every object that satisfies certain condition. But I don't know what's easy, if paint each satisfying node in the graph, or to paint just one at a time (iterating them pushing a "next" button), or any other way.

...

- suggest me a "bottleneck" edge

An iterator could easily do the thing. I will provide the infrastructure.

- show me the shape of the whole graph and I could discover what is

wrong at a glance Yep, this is on my todo list. Having a small portion of the window that shows the whole graph. I will work on this.

Wuuhuu, great!

...

Alexandre

> > > 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

>>> >>> 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

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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 _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel

2:12 p.m.

Hi Martin!

...

So it would be useful to ask the tool things like: - paint / iterate the nodes such [:object | object class == UnexpectedClass]

Having some iterators you mean?

- suggest me a "bottleneck" edge

An iterator could easily do the thing. I will provide the infrastructure.

I inserted visitor. I built a ROHighlighter that highlight some nodes. You can use it like: ROHighlighter for: b in: view. where b is a block. Look for the users of ROHighlighter to see some examples. Let me know if you need more.

...

- show me the shape of the whole graph and I could discover what is wrong at a glance

Yep, this is on my todo list. Having a small portion of the window that shows the whole graph.

I still need to work on this. Cheers, Alexandre

...

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

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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 _______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Martin Dias

5 Dec 5 Dec

6:52 a.m.

A first version of fuel's graph visualization, without expandables yet: "install" Gofer it squeaksource: 'Roassal'; package: 'ConfigurationOfRoassal'; load. (Smalltalk at: #ConfigurationOfRoassal) loadDevelopment. Gofer it url: 'http://ss3.gemstone.com/ss/Fuel'; version: 'Fuel-MartinDias.497'; version: 'FuelPreview-MartinDias.2'; load. "use: - on mouse over, shows printString - on right click, opens inspector " (FLAnalyzer newDefault showPreview analysisFor: (SortedCollection sortBlock: [:a :b | a > b ])) open Martín On Wed, Nov 30, 2011 at 10:12 AM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:

...

Hi Martin!

> So it would be useful to ask the tool things like: > - paint / iterate the nodes such [:object | object class ==

UnexpectedClass]

Having some iterators you mean?

- suggest me a "bottleneck" edge

An iterator could easily do the thing. I will provide the infrastructure.

> - show me the shape of the whole graph and I could discover what is

wrong at a glance

Yep, this is on my todo list. Having a small portion of the window that

shows the whole graph. I still need to work on this. Cheers, Alexandre

> >> >> >> 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

>>>> >>>> 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

>>>> >>>> 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 -- 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 _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Martin Dias

6:55 a.m.

ps: I like the highligther! Martín On Mon, Dec 5, 2011 at 2:52 AM, Martin Dias <tinchodias(a)gmail.com> wrote:

...

Hi Martin!

> So it would be useful to ask the tool things like: > - paint / iterate the nodes such [:object | object class ==

UnexpectedClass]

Having some iterators you mean?

- suggest me a "bottleneck" edge

An iterator could easily do the thing. I will provide the

infrastructure. I inserted visitor. I built a ROHighlighter that highlight some nodes. You can use it like: ROHighlighter for: b in: view. where b is a block. Look for the users of ROHighlighter to see some examples. Let me know if you need more.

> - show me the shape of the whole graph and I could discover what is

wrong at a glance

Yep, this is on my todo list. Having a small portion of the window that

shows the whole graph. I still need to work on this. Cheers, Alexandre

Integer)) asOrderedCollection.

>>> initialNodes do: [:n | >>> n + ROLabel. >>> n @ (ROExpandChildrenOnClick newCalculatingChildrenWith:

[:aClass | aClass subclasses])].

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

>>>> >>>> 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.

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:

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).

Doru to 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."

<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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: 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 _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Alexandre Bergel

8:51 p.m.

Looks good! In FLPreviewAnalysis>>open, add just before to open it: view @RODraggable @ RODraggableWithVelocity. Cheers, Alexandre On 5 Dec 2011, at 02:52, Martin Dias wrote:

...

So it would be useful to ask the tool things like: - paint / iterate the nodes such [:object | object class == UnexpectedClass]

Having some iterators you mean?

- suggest me a "bottleneck" edge

An iterator could easily do the thing. I will provide the infrastructure.

- show me the shape of the whole graph and I could discover what is wrong at a glance

Yep, this is on my todo list. Having a small portion of the window that shows the whole graph.

I still need to work on this. Cheers, Alexandre

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 -- 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 _______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4536

days inactive

4564

days old

moose-dev@list.inf.unibe.ch

Manage subscription

21 comments

4 participants

tags (0)

participants (4)

Alexandre Bergel
Johan Fabry
Martin Dias
Tudor Girba