[Pharo-project] Roassal Survey
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much! We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal. Thank you very much, Vanessa.
What is it? Thansk Hilaire Le 25/09/2012 16:48, Vanessa Peña Araya a écrit :
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
Roassal is a visualization engine. You can find more information (including screenshots and a screencast) here: http://objectprofile.com/roassal-home.html Thanks, Vanessa. On 09/25/2012 11:57 AM, Hilaire Fernandes wrote:
What is it?
Thansk
Hilaire
Le 25/09/2012 16:48, Vanessa Peña Araya a écrit :
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
I don't know your project scope, but these pointers may help you to grab some features to implement: http://www.tm4.org/mev/features Also take a look into the Circular Genome Viewer: http://wishart.biology.ualberta.ca/cgview/gallery.html specially the browsable maps http://wishart.biology.ualberta.ca/BacMap/cgview_linked_maps/NC_003198/index... check out the Expand+ and Rotate+ operations Other very nice engine is Circos http://circos.ca/ which contains plots that has been published in Science, Nature and PLOS. Cheers, Hernán On 25/09/2012 11:48, Vanessa Peña Araya wrote:
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
This is not that we do not have ideas :-) Our todo list includes: - book chapter on Roassal - exporters (e.g., HTML, SVG, JavaScript) - semantic zooming - way to compose shapes - scalability We obtained this list from our personal needs and the need of the Moose and VW communities. Vanessa is working on a proposal for ESUG to help us on the development of Roassal. We are therefore surveying the Pharo community in case of there is a wished feature that we did not see or did not put high on our todolist. We are currently maintaining Roassal (i.e., fixing bugs) and pursuing our innovation effort (i.e., implementing cool ideas). The ESUG support will help us increase our productivity. And yes, we would love to see someone use Roassal to visualize genome, DNA and other biological data. We are ready to provide a strong support. Cheers, Alexandre On Sep 25, 2012, at 12:33 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
I don't know your project scope, but these pointers may help you to grab some features to implement:
http://www.tm4.org/mev/features
Also take a look into the Circular Genome Viewer: http://wishart.biology.ualberta.ca/cgview/gallery.html
specially the browsable maps
http://wishart.biology.ualberta.ca/BacMap/cgview_linked_maps/NC_003198/index...
check out the Expand+ and Rotate+ operations
Other very nice engine is Circos
which contains plots that has been published in Science, Nature and PLOS.
Cheers,
Hernán
On 25/09/2012 11:48, Vanessa Peña Araya wrote:
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Tue, Sep 25, 2012 at 10:15 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
This is not that we do not have ideas :-)
Our todo list includes: - book chapter on Roassal - exporters (e.g., HTML, SVG, JavaScript) - semantic zooming - way to compose shapes - scalability
We obtained this list from our personal needs and the need of the Moose and VW communities.
Vanessa is working on a proposal for ESUG to help us on the development of Roassal. We are therefore surveying the Pharo community in case of there is a wished feature that we did not see or did not put high on our todolist. We are currently maintaining Roassal (i.e., fixing bugs) and pursuing our innovation effort (i.e., implementing cool ideas). The ESUG support will help us increase our productivity.
Thank you Alex & Vanessa for all your great work on Roassal !
And yes, we would love to see someone use Roassal to visualize genome, DNA and other biological data. We are ready to provide a strong support.
I'm really interested to push Roassal in this direction. I have a colleague who is working on epidemiological modeling and he needs to be able to visualize epidemiological data from Vietnam from a lot of diseases in order to discover some patterns. He already done some work by hand and definitively need some way to automate the process. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
I have a colleague who is working on epidemiological modeling and he needs to be able to visualize epidemiological data from Vietnam from a lot of diseases in order to discover some patterns. He already done some work by hand and definitively need some way to automate the process.
Sound interesting! Let's talk about this during your visit in Chile Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
You asked for it.... Three scenarios... 1. Mind Mapping tool similar to http://freemind.sourceforge.net <http://freemind.sourceforge.net/> - MEDIUM priority. I think Roassal would provide a lot of advantages to such an application - and in return be a great reference case for testing interactions - and great possibilities of running Smalltalk scripts against the graph - and draw new users unwittingly to learn Smalltalk. 2. Project Management Tool similar to Microsoft Project - LOW priority. The two main players in the project management space are Primevera and Microsoft Project. Most of the features of these are overkill for most small projects and actually never used by users. Many people use VERY basic features of Microsoft Project to just manually build nice looking dependency graphs. This part Roassal could do very well. Over time other contributors with more project management domain knowledge might build in more sophisticated features. A Smalltalk backed project management scripting tool would be really great. And again, new users drawn just to the application may be unwittingly introduced to Smalltalk (and of course, once introduced are hooked for life). 3. Electrical Software Development Platform - CRITICAL priority Of course, my own project to complete my masters within the next couple of months!! This is implementing a model browser for the IEC 61970 Common Information Model. I showed this to Alex a while ago and am just now getting back to the point I was at before switching from Mondrian to Roassal. While this has taken a while I am very happy with the additional control I have with Roassal (and a lot of this time has been too many demands by my day job). Perhaps a rough early release is not too far away. And four features... (some of these may just be not knowing how to apply existing features) ... 4. Static layouts saved to file - CRITICAL priority. I need to be able to arrange the elements in a Roassal graph, then save that to disk and later load this up in another image. I suspect that doing this using Fuel would be very cool. 5. Static Magritte-Roassal links - CRITICAL priority. Currently in my use of the Magritte-Roassal combination, if in Magritte I select an element and then drag elements to arrange then in the "downstream" Roassal graph, when I select another Magritte item, my arrangement is lost as the layout is reapplied to the whole graph. What I would like is for Roassal to highlight the item selected in Magritte without reapplying layout to the graph. A layout would only be applied to a graph when manually applied - much like the ROMondrianExample>>chooseLayout. 6. Swapping between static layouts - HIGH priority As well, for a single model I need be able to have several views in one window pane, where in one I put nodes into one arrangement, change to another view where I put nodes into another arrangement and flip back and forth between the two arrangements. 7. Constrain elements so they can't overlap - MEDIUM priority. Currently nodes are initially laid out so that they don't overlap, however there is no constraint on them from being moved so that they later overlap. It would be good if elements could be constrained from so that they could not overlap. Similar to how moving a child element past the border of the parent dynamically resizes the parent, trying to move a first element over the top of a second element would either: (a.) push the second element in the direction the first element it is being dragged; or (b.) the first element would get stuck at the edge of the second element. In both cases, the subsequent behavior could be: (c.) the first and second elements continue to interact in the same regardless of how far the mouse moves; or (d.) once the mouse has moved past the bounds of the second element, the first and second element swap positions. 8 Interactively creating graphs - MEDIUM priority Creating a graph by adding elements from within the Roassal graph and adding edges by dragging links between two elements. Just before I started switching my application from Mondrian to Roassal, I added this functionality to Mondrian and soon I need to re-implement this in Roassal. Having done it once in Mondrian I reckon I've a good chance of doing the same for Roassal, where as I can't do (4.) & (5.) myself. hope this helps, cheers -ben Alexandre Bergel wrote:
This is not that we do not have ideas :-)
Our todo list includes: - book chapter on Roassal - exporters (e.g., HTML, SVG, JavaScript) - semantic zooming - way to compose shapes - scalability
We obtained this list from our personal needs and the need of the Moose and VW communities.
Vanessa is working on a proposal for ESUG to help us on the development of Roassal. We are therefore surveying the Pharo community in case of there is a wished feature that we did not see or did not put high on our todolist. We are currently maintaining Roassal (i.e., fixing bugs) and pursuing our innovation effort (i.e., implementing cool ideas). The ESUG support will help us increase our productivity.
And yes, we would love to see someone use Roassal to visualize genome, DNA and other biological data. We are ready to provide a strong support.
Cheers, Alexandre
On Sep 25, 2012, at 12:33 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
I don't know your project scope, but these pointers may help you to grab some features to implement:
http://www.tm4.org/mev/features
Also take a look into the Circular Genome Viewer: http://wishart.biology.ualberta.ca/cgview/gallery.html
specially the browsable maps
http://wishart.biology.ualberta.ca/BacMap/cgview_linked_maps/NC_003198/index...
check out the Expand+ and Rotate+ operations
Other very nice engine is Circos
which contains plots that has been published in Science, Nature and PLOS.
Cheers,
Hernán
On 25/09/2012 11:48, Vanessa Peña Araya wrote:
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
Thank you, Ben. And yes, this is the kind of things that are very useful.
3. Electrical Software Development Platform - CRITICAL priority Of course, my own project to complete my masters within the next couple of months!! This is implementing a model browser for the IEC 61970 Common Information Model. I showed this to Alex a while ago and am just now getting back to the point I was at before switching from Mondrian to Roassal. While this has taken a while I am very happy with the additional control I have with Roassal (and a lot of this time has been too many demands by my day job). Perhaps a rough early release is not too far away. I'm sorry but I don't know this, so I don't understand really. Is there some place I can see it?
As yes, the features you mentioned are interesting. You are not the first to mention features 4, for example. Thank you very much :) Vanessa.
Alexandre Bergel wrote:
This is not that we do not have ideas :-)
Our todo list includes: - book chapter on Roassal - exporters (e.g., HTML, SVG, JavaScript) - semantic zooming - way to compose shapes - scalability
We obtained this list from our personal needs and the need of the Moose and VW communities.
Vanessa is working on a proposal for ESUG to help us on the development of Roassal. We are therefore surveying the Pharo community in case of there is a wished feature that we did not see or did not put high on our todolist. We are currently maintaining Roassal (i.e., fixing bugs) and pursuing our innovation effort (i.e., implementing cool ideas). The ESUG support will help us increase our productivity.
And yes, we would love to see someone use Roassal to visualize genome, DNA and other biological data. We are ready to provide a strong support.
Cheers, Alexandre
On Sep 25, 2012, at 12:33 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
I don't know your project scope, but these pointers may help you to grab some features to implement:
http://www.tm4.org/mev/features
Also take a look into the Circular Genome Viewer: http://wishart.biology.ualberta.ca/cgview/gallery.html
specially the browsable maps
http://wishart.biology.ualberta.ca/BacMap/cgview_linked_maps/NC_003198/index...
check out the Expand+ and Rotate+ operations
Other very nice engine is Circos
which contains plots that has been published in Science, Nature and PLOS.
Cheers,
Hernán
On 25/09/2012 11:48, Vanessa Peña Araya wrote:
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
Hello everybody, During the weekend I had a look at the Roassal project and I found it very good. Moreover I find that asking around the community for good ideas to drive the future of the project a cool initiative. About that, I completely agree with Ben's first 3 directions. Other cool ideas in terms of ergonomy can be found in the Yed<http://www.yworks.com/en/products_yed_about.html>graph drawing tool.
From my experience working on computer-aided design tools for the electrical (electronical) industry i can say that one very important feature that these kind of tools need is the ability to create/edit large hierarchical graphs. From my perspective a electrical circuit is nothing more than a large graph of interconnected elements with each node representing a physical device. Hierarchical composition of such structures is necessary to ease the understanding of the system. In consequence IMHO being able to easily dive-in and get-out of hierarchical components is the most important feature that Roassal is missing right now. Just imagine looking at a layed-out graph of ten interconnected nodes, then just by clicking on one of these nodes the view is replaced by another graph representing the inner components. Furthermore I believe that such an approach can be abstracted away to more complex interactions (opening a view with an editor window on that particular instance of the node, etc).
Another feature that I think it is missing in most (if not all) graph viewers/layout systems/editors is the possibility to have connection ports on the hierarchical nodes in order to preserve the connections passing through the hierarchy. some pointers: http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-architec... http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf Cheers, Ciprian Teodorov On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <van.c.pena@gmail.com> wrote:
Thank you, Ben. And yes, this is the kind of things that are very useful.
3. Electrical Software Development Platform - CRITICAL priority
Of course, my own project to complete my masters within the next couple of months!! This is implementing a model browser for the IEC 61970 Common Information Model. I showed this to Alex a while ago and am just now getting back to the point I was at before switching from Mondrian to Roassal. While this has taken a while I am very happy with the additional control I have with Roassal (and a lot of this time has been too many demands by my day job). Perhaps a rough early release is not too far away.
I'm sorry but I don't know this, so I don't understand really. Is there some place I can see it?
As yes, the features you mentioned are interesting. You are not the first to mention features 4, for example.
Thank you very much :)
Vanessa.
Alexandre Bergel wrote:
This is not that we do not have ideas :-)
Our todo list includes: - book chapter on Roassal - exporters (e.g., HTML, SVG, JavaScript) - semantic zooming - way to compose shapes - scalability
We obtained this list from our personal needs and the need of the Moose and VW communities.
Vanessa is working on a proposal for ESUG to help us on the development of Roassal. We are therefore surveying the Pharo community in case of there is a wished feature that we did not see or did not put high on our todolist. We are currently maintaining Roassal (i.e., fixing bugs) and pursuing our innovation effort (i.e., implementing cool ideas). The ESUG support will help us increase our productivity.
And yes, we would love to see someone use Roassal to visualize genome, DNA and other biological data. We are ready to provide a strong support.
Cheers, Alexandre
On Sep 25, 2012, at 12:33 PM, Hernán Morales Durand < hernan.morales@gmail.com> wrote:
I don't know your project scope, but these pointers may help you to
grab some features to implement:
http://www.tm4.org/mev/**features <http://www.tm4.org/mev/features>
Also take a look into the Circular Genome Viewer: http://wishart.biology.**ualberta.ca/cgview/gallery.**html<http://wishart.biology.ualberta.ca/cgview/gallery.html>
specially the browsable maps
http://wishart.biology.**ualberta.ca/BacMap/cgview_** linked_maps/NC_003198/index.**html<http://wishart.biology.ualberta.ca/BacMap/cgview_linked_maps/NC_003198/index...>
check out the Expand+ and Rotate+ operations
Other very nice engine is Circos
which contains plots that has been published in Science, Nature and PLOS.
Cheers,
Hernán
On 25/09/2012 11:48, Vanessa Peña Araya wrote:
Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
Thanks Ciprian! Cheers, Alexandre On Sep 26, 2012, at 3:49 PM, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hello everybody,
During the weekend I had a look at the Roassal project and I found it very good. Moreover I find that asking around the community for good ideas to drive the future of the project a cool initiative.
About that, I completely agree with Ben's first 3 directions. Other cool ideas in terms of ergonomy can be found in the Yed graph drawing tool.
From my experience working on computer-aided design tools for the electrical (electronical) industry i can say that one very important feature that these kind of tools need is the ability to create/edit large hierarchical graphs. From my perspective a electrical circuit is nothing more than a large graph of interconnected elements with each node representing a physical device. Hierarchical composition of such structures is necessary to ease the understanding of the system. In consequence IMHO being able to easily dive-in and get-out of hierarchical components is the most important feature that Roassal is missing right now. Just imagine looking at a layed-out graph of ten interconnected nodes, then just by clicking on one of these nodes the view is replaced by another graph representing the inner components. Furthermore I believe that such an approach can be abstracted away to more complex interactions (opening a view with an editor window on that particular instance of the node, etc).
Another feature that I think it is missing in most (if not all) graph viewers/layout systems/editors is the possibility to have connection ports on the hierarchical nodes in order to preserve the connections passing through the hierarchy.
some pointers:
http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-architec...
http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf
Cheers,
Ciprian Teodorov
On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <van.c.pena@gmail.com> wrote: Thank you, Ben. And yes, this is the kind of things that are very useful.
3. Electrical Software Development Platform - CRITICAL priority Of course, my own project to complete my masters within the next couple of months!! This is implementing a model browser for the IEC 61970 Common Information Model. I showed this to Alex a while ago and am just now getting back to the point I was at before switching from Mondrian to Roassal. While this has taken a while I am very happy with the additional control I have with Roassal (and a lot of this time has been too many demands by my day job). Perhaps a rough early release is not too far away. I'm sorry but I don't know this, so I don't understand really. Is there some place I can see it?
As yes, the features you mentioned are interesting. You are not the first to mention features 4, for example.
Thank you very much :)
Vanessa.
Alexandre Bergel wrote: This is not that we do not have ideas :-)
Our todo list includes: - book chapter on Roassal - exporters (e.g., HTML, SVG, JavaScript) - semantic zooming - way to compose shapes - scalability
We obtained this list from our personal needs and the need of the Moose and VW communities.
Vanessa is working on a proposal for ESUG to help us on the development of Roassal. We are therefore surveying the Pharo community in case of there is a wished feature that we did not see or did not put high on our todolist. We are currently maintaining Roassal (i.e., fixing bugs) and pursuing our innovation effort (i.e., implementing cool ideas). The ESUG support will help us increase our productivity.
And yes, we would love to see someone use Roassal to visualize genome, DNA and other biological data. We are ready to provide a strong support.
Cheers, Alexandre
On Sep 25, 2012, at 12:33 PM, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
I don't know your project scope, but these pointers may help you to grab some features to implement:
http://www.tm4.org/mev/features
Also take a look into the Circular Genome Viewer: http://wishart.biology.ualberta.ca/cgview/gallery.html
specially the browsable maps
http://wishart.biology.ualberta.ca/BacMap/cgview_linked_maps/NC_003198/index...
check out the Expand+ and Rotate+ operations
Other very nice engine is Circos
which contains plots that has been published in Science, Nature and PLOS.
Cheers,
Hernán
On 25/09/2012 11:48, Vanessa Peña Araya wrote: Hello! As you probably know, Roassal was presented at ESUG. We received a lot of positive feedback from you and also a lot of request for features. Thank you very much!
We want to start working on this, but also prioritize what seems to be more urgent. For this, we would like to survey the community about 1 - what are the features you would like to see in Roassal. Please, provide a list of features requests and tell us about their priority 2 - scenarios where you would like to use Roassal.
Thank you very much, Vanessa.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ciprian Teodorov wrote:
Another feature that I think it is missing in most (if not all) graph viewers/layout systems/editors is the possibility to have connection ports on the hierarchical nodes in order to preserve the connections passing through the hierarchy.
some pointers:
http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-architec...
http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf
Cheers,
Ciprian Teodorov
On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <van.c.pena@gmail.com> wrote:
Ciprian, I have skimmed through those links but can't quite understand your comment "in order to preserve the connections passing through the hierarchy" Can you expand some more on that - perhaps with a mock up in a paint program? If you are interested in following the development of Roassal, perhaps move your follow up to https://www.iam.unibe.ch/mailman/listinfo/moose-dev. <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> I have been very encouraged by the clean architecture and the responsiveness of the main developers to feature suggestions. cheers, Ben
Hi Ben, Sorry for the delay, I was very bussy these last few days. Attached to this mail you will find some drawings showing what I mean. The first attachement [1] show the two most important graph concepts that are needed for circuit design: the support for hyper-edges, and the ports crossing hierarchical nodes. The hyper-edges are useful to represent physical wires (which are connected to a source, and then provide input to a number of sinks). The hierarchical crossings can be thought as the physical pins of an integrated circuit, that are plugged into a socket in order to integrate that circuit into a system. The second, and third attachement are the same (only the format differs pdf vs png). They show a detailed example of the hierarchical structure that I imagine. The main elements of this graphs are: the leaf nodes, the edges, the hierarchical nodes, the pins, and the ports. The leaf nodes are just the typical graph nodes. The edges are just links between nodes. The hierarchical nodes are graphs themselves, but they can be connected one to another using edges. However these connections between hierarchical nodes are done through the pins present on their interface. If such a hierarchical node wants to be connected to the exterior it has to have pins so that the layout algorithm can be constrained to route the edges to these pins (which can be either free or have fixed positions). The ports in my figure are just ways to group together a number of pins. In the figure you will see three graphs (corresponding to three views on the leftmost graph). The first one (on the left) just represents the top-level graph with all hierarchical nodes collapsed. This graph itself has a number of ports so that it can be embedded in another one. The second one (in the middle) shows an expanded view of the central hierarchical node in the top-level graph. This one is expanded into another view. The third one (in the right) shows yet another expanded view, this time of a node in the middle graph. This last graph contains two hierarchical nodes itself that are expanded in place. Now the idea of edges crossing hierarchy boundaries through pins is that the inner-most hierarchical nodes can be layed out separately and then collapsed, their containers can be layed out just like a simple graph (in the case their nodes are collapsed). However if one node is a hierarchical one, and is expanded, the layout algorithm does not have to layout the contents inside this hierarchical node, it just layouts the whole graph considering the pins as fixed nodes to which it will route the links. This way when expanded the hierarchical nodes retain their initial layout, moreover this initial layout takes into account the fact that the node will be embedded into a larger graph and thus it will place the pins on the boundary. FYI the graphs shown in the last two attachements where automatically generated from a circuit design, they were imported into the Yed diagram editor, one by one, layed out semi-automatically (used force-based layout initially, an then moved a number of nodes manually to align them well - ex the straight edges were obtained by manually moving the nodes). Just imagine how boring this process is. Moreover since I had to represent the pins, and the ports just as plain graph nodes grouped together the layout algorithms don't have any idea that these nodes are special, thus they place them everywhere, even more if the groups are expanded their inner nodes are layouted along with the embedding hierarchy... resulting in a mess. Cheers, Ciprian * * *References:* [1] Miro Sponemann, Hauke Fuhrmann, Reinhard von Hanxleden, and Petra Mutzel. Port constraints in hierarchical layout of data flow<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> diagrams<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> . In David Eppstein and Emden Gansner, editors, Graph Drawing, volume 5849 of Lecture Notes in Computer Science, chapter 14. Springer Berlin / Heidelberg, Berlin, Heidelberg, 2010. On Thu, Sep 27, 2012 at 3:35 PM, Ben Coman <btc@openinworld.com> wrote:
Ciprian Teodorov wrote:
Another feature that I think it is missing in most (if not all) graph viewers/layout systems/editors is the possibility to have connection ports on the hierarchical nodes in order to preserve the connections passing through the hierarchy.
some pointers:
http://www.slideshare.net/**teodorov/tools-and-**crossbarbased-nanocmos-* *architectures<http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-architec...>
Cheers,
Ciprian Teodorov
On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <van.c.pena@gmail.com> wrote:
Ciprian,
I have skimmed through those links but can't quite understand your comment "in order to preserve the connections passing through the hierarchy" Can you expand some more on that - perhaps with a mock up in a paint program?
If you are interested in following the development of Roassal, perhaps move your follow up to https://www.iam.unibe.ch/** mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>. <https://www.iam.unibe.ch/**mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
I have been very encouraged by the clean architecture and the responsiveness of the main developers to feature suggestions.
cheers, Ben
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
Ciprian, Thanks for your detailed reply. Some comments inline... Ciprian Teodorov wrote:
Hi Ben,
Sorry for the delay, I was very bussy these last few days. Attached to this mail you will find some drawings showing what I mean.
The first attachement [1] show the two most important graph concepts that are needed for circuit design: the support for hyper-edges, and the ports crossing hierarchical nodes. The hyper-edges are useful to represent physical wires (which are connected to a source, and then provide input to a number of sinks).
hyper-edges: Can you comment on how close Roassal Easel > #ROMondrianExample > #edges > orthoVerticalLine comes to your need for hyper-edges. Try arranging the nodes in various configurations. Note however... that where you have three "ortho" segments making up an edge and it looks like the first segment is shared by all edges, actually each edge has three segments each and the first segments are being drawn over the top of each other. Would that be significant?
The hierarchical crossings can be thought as the physical pins of an integrated circuit, that are plugged into a socket in order to integrate that circuit into a system.
hierarchical-crossing: Check out Roassal Easel > #ROMondrianExample > #edges > attachPoint. Also look at the coding of ROAttachPoint and subclasses, and in particular ROShorterDistanceAttachPoint>>fourFromPointsOfEdge: and
fourToPointsOfEdge:. I think the way this has been done is quite elegant and building on these to create hierarchical-crossings might not be too hard. You might try it. Perhaps these might be called ROOuterAttachPoint and ROInnerAttachPoint and would respectively check to see if the connecting element is a contained sub-element.
Alexandre, I think this example shows what I was badly hinting at with my "ROElement>>mostSpecificParentCommonWith:" thread. This used to decide which level within a hierarchy of sub-element edges are stored. Referring to the first attachement of Cipirian's post "Figure 2(a)", I think in this case the "inner" edges should be stored as part of the "Composite" element, but I think currently they would be stored in the parent of "Composite". Also I had been thinking for a while that it would be nice to be able to have AttachPoints rendered - both as permanently-visible and also visible-on-hover-only, so that when I re-implement the edge rubber-banding to interactive draw lines between elements (which I demoed to you a while ago on Mondrian) the user could drop the edge-end onto a specific AttachPoint.
The second, and third attachement are the same (only the format differs pdf vs png). They show a detailed example of the hierarchical structure that I imagine. The main elements of this graphs are: the leaf nodes, the edges, the hierarchical nodes, the pins, and the ports. The leaf nodes are just the typical graph nodes. The edges are just links between nodes. The hierarchical nodes are graphs themselves, but they can be connected one to another using edges. However these connections between hierarchical nodes are done through the pins present on their interface. If such a hierarchical node wants to be connected to the exterior it has to have pins so that the layout algorithm can be constrained to route the edges to these pins (which can be either free or have fixed positions). The ports in my figure are just ways to group together a number of pins.
In the figure you will see three graphs (corresponding to three views on the leftmost graph). The first one (on the left) just represents the top-level graph with all hierarchical nodes collapsed. This graph itself has a number of ports so that it can be embedded in another one. The second one (in the middle) shows an expanded view of the central hierarchical node in the top-level graph. This one is expanded into another view. The third one (in the right) shows yet another expanded view, this time of a node in the middle graph. This last graph contains two hierarchical nodes itself that are expanded in place.
Now the idea of edges crossing hierarchy boundaries through pins is that the inner-most hierarchical nodes can be layed out separately and then collapsed, their containers can be layed out just like a simple graph (in the case their nodes are collapsed). However if one node is a hierarchical one, and is expanded, the layout algorithm does not have to layout the contents inside this hierarchical node, it just layouts the whole graph considering the pins as fixed nodes to which it will route the links. This way when expanded the hierarchical nodes retain their initial layout, moreover this initial layout takes into account the fact that the node will be embedded into a larger graph and thus it will place the pins on the boundary.
What do you think of Roassal Easel > Examples > ROExample > #interaction
zooming and ROExample > #interaction > expandableNodesOn: ?
FYI the graphs shown in the last two attachements where automatically generated from a circuit design, they were imported into the Yed diagram editor, one by one, layed out semi-automatically (used force-based layout initially, an then moved a number of nodes manually to align them well - ex the straight edges were obtained by manually moving the nodes). Just imagine how boring this process is. Moreover since I had to represent the pins, and the ports just as plain graph nodes grouped together the layout algorithms don't have any idea that these nodes are special, thus they place them everywhere, even more if the groups are expanded their inner nodes are layouted along with the embedding hierarchy... resulting in a mess.
Cheers, Ciprian * * *References:* [1] Miro Sponemann, Hauke Fuhrmann, Reinhard von Hanxleden, and Petra Mutzel. Port constraints in hierarchical layout of data flow<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> diagrams<http://rtsys.informatik.uni-kiel.de/~biblio/downloads/papers/gd09.pdf> . In David Eppstein and Emden Gansner, editors, Graph Drawing, volume 5849 of Lecture Notes in Computer Science, chapter 14. Springer Berlin / Heidelberg, Berlin, Heidelberg, 2010.
On Thu, Sep 27, 2012 at 3:35 PM, Ben Coman <btc@openinworld.com> wrote:
Ciprian Teodorov wrote:
Another feature that I think it is missing in most (if not all) graph viewers/layout systems/editors is the possibility to have connection ports on the hierarchical nodes in order to preserve the connections passing through the hierarchy.
some pointers:
http://www.slideshare.net/**teodorov/tools-and-**crossbarbased-nanocmos-* *architectures<http://www.slideshare.net/teodorov/tools-and-crossbarbased-nanocmos-architec...>
Cheers,
Ciprian Teodorov
On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <van.c.pena@gmail.com> wrote:
Ciprian,
I have skimmed through those links but can't quite understand your comment "in order to preserve the connections passing through the hierarchy" Can you expand some more on that - perhaps with a mock up in a paint program?
If you are interested in following the development of Roassal, perhaps move your follow up to https://www.iam.unibe.ch/** mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>. <https://www.iam.unibe.ch/**mailman/listinfo/moose-dev<https://www.iam.unibe.ch/mailman/listinfo/moose-dev>
I have been very encouraged by the clean architecture and the responsiveness of the main developers to feature suggestions.
cheers, Ben
------------------------------------------------------------------------
Alexandre, I think this example shows what I was badly hinting at with my "ROElement>>mostSpecificParentCommonWith:" thread. This used to decide which level within a hierarchy of sub-element edges are stored. Referring to the first attachement of Cipirian's post "Figure 2(a)", I think in this case the "inner" edges should be stored as part of the "Composite" element, but I think currently they would be stored in the parent of "Composite".
if you check the sender of #mostSpecificParentCommonWith: then you will see that only the Mondrian builder makes use of it. Currently, and outside the Mondrian DSL, you can insert the edge where you actually want, independently of its extremities.
Also I had been thinking for a while that it would be nice to be able to have AttachPoints rendered - both as permanently-visible and also visible-on-hover-only, so that when I re-implement the edge rubber-banding to interactive draw lines between elements (which I demoed to you a while ago on Mondrian) the user could drop the edge-end onto a specific AttachPoint.
This should be easy to do. However before to work on this, I have a question about what Roassal currently offers. In Roassal, lines knows about the attach points, i.e., the class ROLine has a variable called 'attachPoint', intended to hold an instance of ROAttachPoint. It is therefore not the node the is aware of it. It is more flexible in my opinion than what traditional drawing tools offers. I am wondering whether this is what we really want. Shouldn't the element/node be aware of its attachpoint, instead of its edges? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Our todo list includes: - book chapter on Roassal
Maybe don't bother with that. Write short blog posts showing the stuff you can currently do with Roassal. And keep writing as the project evolves. I feel like the time a book is out, it's already outdated by the implementation.
Our todo list includes: - book chapter on Roassal
Maybe don't bother with that. Write short blog posts showing the stuff you can currently do with Roassal. And keep writing as the project evolves.
I feel like the time a book is out, it's already outdated by the implementation.
:-) Well... My students are asking for a piece of documentation. And in my opinion, book chapter are more read than blog :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 26/09/12 15:19, Alexandre Bergel wrote:
Our todo list includes: - book chapter on Roassal
Maybe don't bother with that. Write short blog posts showing the stuff you can currently do with Roassal. And keep writing as the project evolves.
I feel like the time a book is out, it's already outdated by the implementation.
:-) Well... My students are asking for a piece of documentation. And in my opinion, book chapter are more read than blog :-)
You're right, a book has probably more authority than a blog post. And its probably more perenial as well. But a blog post is more aligned with *my* way of consuming tech/programming/library/framework information :p
participants (8)
-
Alexandre Bergel -
Ben Coman -
Ciprian Teodorov -
Francois Stephany -
Hernán Morales Durand -
Hilaire Fernandes -
Serge Stinckwich -
Vanessa Peña Araya