Smalltalk › Pharo › Pharo Smalltalk Developers

Roassal Survey

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

vpena

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.

Hilaire Fernandes

Re: Roassal Survey

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

vpena

Re: Roassal Survey

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.

hernanmd

Re: Roassal Survey

In reply to this post by vpena

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

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:

abergel

Re: Roassal Survey

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 <[hidden email]> 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.html
>
> 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.
>>
>>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

SergeStinckwich

Re: Roassal Survey

On Tue, Sep 25, 2012 at 10:15 PM, Alexandre Bergel
<[hidden email]> wrote:

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/

abergel

Re: Roassal Survey

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

Ben Coman

Re: Roassal Survey

In reply to this post by abergel

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 <[hidden email]> 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.html
>>
>> 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.
>>>
>>>
>>>
>>
>
>

vpena

Re: Roassal Survey

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
>> <[hidden email]> 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.html
>>>
>>>
>>> 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.
>>>>
>>>>
>>
>
>
>

Ciprian Teodorov-3

Re: Roassal Survey

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

http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf

Cheers,

Ciprian Teodorov

On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <[hidden email]> 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 <[hidden email]> 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.html

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.

abergel

Re: Roassal Survey

Thanks Ciprian!

Cheers,
Alexandre

On Sep 26, 2012, at 3:49 PM, Ciprian Teodorov <[hidden email]> 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-architectures
>
> http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf
>
>
>
> Cheers,
>
> Ciprian Teodorov
>
>
>
> On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <[hidden email]> 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 <[hidden email]> 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.html
>
> 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.
>
>
>
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

fstephany

Re: Roassal Survey

In reply to this post by abergel

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

abergel

Re: Roassal Survey

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

fstephany

Re: Roassal Survey

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

Ben Coman

Re: Roassal Survey

In reply to this post by Ciprian Teodorov-3

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://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf
>
>
> Cheers,
>
> Ciprian Teodorov
>
>
> On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <[hidden email]> 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

Ciprian Teodorov-3

Re: Roassal Survey

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

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 <[hidden email]> 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://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf

Cheers,

Ciprian Teodorov

On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <[hidden email]> 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

--
Dr. Ciprian TEODOROV
Ingénieur Développement CAO

tél : 06 08 54 73 48
mail : [hidden email]
www.teodorov.ro

hyperedges-and-graph-ports.pdf (149K) Download Attachment

hierarchical port graph.pdf (1M) Download Attachment

hierarchical port graph.png (717K) Download Attachment

Ben Coman

Re: Roassal Survey

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 <[hidden email]> 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-architectures>
>>>
>>> http://stiff.univ-brest.fr/~**cteodorov/manuscript-teodorov_**FINAL.pdf<http://stiff.univ-brest.fr/~cteodorov/manuscript-teodorov_FINAL.pdf>
>>>
>>>
>>> Cheers,
>>>
>>> Ciprian Teodorov
>>>
>>>
>>> On Sep 26, 2012 6:16 PM, "Vanessa Peña Araya" <[hidden email]>
>>> 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
>>
>>
>>
>
>
>
>
> ------------------------------------------------------------------------
>

abergel

Re: Roassal Survey

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