Smalltalk › Pharo › Pharo Smalltalk Users

Call for action for Roassal

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

35 messages Options

jfabry

Re: [Moose-dev] Re: Re: Call for action for Roassal

Heh, also a funny feature of your anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-)

| v lbls es e1 e2 a1 a2 layout stepping|

v := RTView new.

lbls := RTLabel new elementsOn: #(#First #Second).

es := RTEllipse new

size: 30;

borderColor: Color black;

elementsOn: #(#source #dest).

addAll: lbls;

addAll: es.

es @ RTDraggable.

es @ RTLabeled.

e1 := RTArrowedLine new

withContinuousCircleAttachPoint;

color: Color black;

edgeFrom: es first to: es second.

v add: e1.

e2 := RTArrowedLine new

withContinuousCircleAttachPoint;

color: Color black;

edgeFrom: es second to: es first.

v add: e2.

a1 := RTAnchorConstraint new.

a1 anchorShape size: 10.

a1 guideLine color: Color red.

element: lbls first;

edge: e1;

balance: 0.2;

minDistance: 10;

build.

(a2 := RTAnchorConstraint new)

element: lbls second;

edge: e2;

balance: 0.2;

minDistance: 10;

build.

layout := RTForceBasedLayout new

charge: -450; length: 100;

doNotUseProgressBar; applyOn: es; yourself.

layout initialLayout: RTSugiyamaLayout new.

stepping := RTSpringLayoutStepping new

view: v; layout: layout;

afterBlock: [ v canvas camera focusOnCenter].

v addAnimation: stepping.

^ v

On Mar 9, 2016, at 17:56, Johan Fabry <[hidden email]> wrote:

On Mar 7, 2016, at 11:34, Peter Uhnák <[hidden email]> wrote:

I've just commited RTAnchorConstraint to latest Roassal, see class-side example there.

I have been trying it, and there is a first version that works now, thanks!

I even have a bug report for you … before, when I removed the edge, the label was also removed automatically. Now this is no longer the case. :-(

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Peter Uhnak

Re: [Moose-dev] Re: Re: Call for action for Roassal

On Wed, Mar 9, 2016 at 10:02 PM, Johan Fabry <[hidden email]> wrote:

Heh, also a funny feature of your anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-)

can't help myself :)

https://youtu.be/PGNiXGX2nLU?t=1m

stepping := RTSpringLayoutStepping new
view: v; layout: layout;
afterBlock: [ v canvas camera focusOnCenter].

The problem is that RTSpringLayoutStepping>>view sets in effect the layout on all elements in the view, which obviously won't work since they'll start competing.

I'm not sure right now how to address it, but try this

stepping := RTSpringLayoutStepping new

view: RTView new; layout: layout;

nodes: es;

afterBlock: [ v canvas camera focusOnCenter].

I even have a bug report for you … before, when I removed the edge, the label was also removed automatically. Now this is no longer the case. :-(

Ah right, thanks. I've extracted the class from my code and I have different removal mechanism...

Please try the latest version, it should be fixed there.

Peter

Martin Bähr-2

Re: Call for action for Roassal

In reply to this post by stepharo

hi,

i just remembered two things:

i'd like to see rounded corners on nodes.

Excerpts from stepharo's message of 2016-02-24 12:42:49 +0100:
> - having a better output (arrows, edge)

and related to edges:

i'd like edges to connect to a node on the border of the box, not to the center
of the node. this means the connecting point would always be at the middle of
the side of one edge:

___\|/___
| |
\| |/
--| |--
/| |\
|_________|
/|\

bezier edges should always leave at a 90deg angle:
____|____
| |
| |
--| |--
| |
|_________|
|

optionally, starting at the corners could also be nice:

\_________/
| |
| |
| |
| |
|_________|
/ \

and in such a case bezier edges should leave at 135deg to each side.

by default the edge should find the nearest connection point, but i'd like to
configure a list of allowed points.

finally, multiple edges in the same general direction should either leave at
the same point, pick the nearest side that doesn't have an edge already.
or spaced evenly along the same side if all available sides have edges already.

the list of allowed connection points would have 12 options:
the middle of 4 sides, 4 corners, and 4 sides as a whole when multiple edges
should be spaced evenly.

greetings, martin.

--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
secretary beijinglug.org
mentor fossasia.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/

Peter Uhnak

Re: Call for action for Roassal

On Thu, Mar 10, 2016 at 12:36 AM, Martin Bähr <[hidden email]> wrote:

hi,

i just remembered two things:

i'd like to see rounded corners on nodes.

We've added this quite some time ago, unless you have something else in mind.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

|v e|

v := RTView new.

e := RTRoundedBox new

size: 100;

borderRadius: 20;

borderColor: Color black;

borderWidth: 1;

element.

v add: e.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Excerpts from stepharo's message of 2016-02-24 12:42:49 +0100:
> - having a better output (arrows, edge)

and related to edges:

i'd like edges to connect to a node on the border of the box, not to the center
of the node. this means the connecting point would always be at the middle of
the side of one edge:

We have about 10 different attach points already. See the 'attach point' protocol of RTAbstractLine.

Some of them also automatically add extra space if there are multiple lines between the same elements.

As for bezier and multiline edges, their curvature isn't currently handled properly, but it's in my todo list (I'll work on this probably during the weekend).

I'm sure it can be presented in more revealing way, but it's too late for me today (or is it too early?).

You can play with it (drag the elements to see how it behaves).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

|v attachOptions es e offset|

v := RTView new.

attachOptions := RTAbstractLine selectors select: [ :each | each beginsWith: #with ].

offset := 0 @ 0.

attachOptions do: [ :each |

es := RTBox new borderColor: Color black; size: 50; elementsOn: #(a b).

each = #withContinuousCircleAttachPoint

ifTrue: [ es := RTEllipse new borderColor: Color black; size: 50; elementsOn: #(a b). ].

es translateBy: offset.

es @ RTDraggable.

offset := offset + (0 @ 100).

v addAll: es.

es second translateBy: 300 @ 25.

e := RTArrowedLine new

color: Color black;

perform: each;

edgeFrom: es first to: es second.

e model: each.

v add: e.

e @ (RTLabelled new color: Color black).

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

___\|/___
| |
\| |/
--| |--
/| |\
|_________|
/|\

bezier edges should always leave at a 90deg angle:
____|____
| |
| |
--| |--
| |
|_________|
|

optionally, starting at the corners could also be nice:

\_________/
| |
| |
| |
| |
|_________|
/ \

and in such a case bezier edges should leave at 135deg to each side.

by default the edge should find the nearest connection point, but i'd like to
configure a list of allowed points.

finally, multiple edges in the same general direction should either leave at
the same point, pick the nearest side that doesn't have an edge already.
or spaced evenly along the same side if all available sides have edges already.

the list of allowed connection points would have 12 options:
the middle of 4 sides, 4 corners, and 4 sides as a whole when multiple edges
should be spaced evenly.

greetings, martin.

--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
secretary beijinglug.org
mentor fossasia.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/

jfabry

Re: [Moose-dev] RTAnchorConstraint

In reply to this post by Peter Uhnak

On Mar 9, 2016, at 18:51, Peter Uhnák <[hidden email]> wrote:

On Wed, Mar 9, 2016 at 10:02 PM, Johan Fabry <[hidden email]> wrote:
Heh, also a funny feature of your anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-)

can't help myself :)

https://youtu.be/PGNiXGX2nLU?t=1m

Hehe, good one :-) https://youtu.be/uo0o8eQWfcI ! :-P

stepping := RTSpringLayoutStepping new
view: v; layout: layout;
afterBlock: [ v canvas camera focusOnCenter].

The problem is that RTSpringLayoutStepping>>view sets in effect the layout on all elements in the view, which obviously won't work since they'll start competing.

I'm not sure right now how to address it, but try this

stepping := RTSpringLayoutStepping new
view: RTView new; layout: layout;
nodes: es;
afterBlock: [ v canvas camera focusOnCenter].

Sorry, I don’t know enough of the internals to understand what’s going on. The solution is not a solution for me, because it effectively removes the animation, we only see the the resulting layout. There is no other solution? Alex, do you have any idea?

Ah right, thanks. I've extracted the class from my code and I have different removal mechanism...
Please try the latest version, it should be fixed there.

Fixed, thanks!

But now there is a new bug RTAnchorConstraint>>computeExtraDistance that I cannot reliably reproduce, I only have a stack trace, sorry:

Array(Object)>>errorSubscriptBounds:

Array(Object)>>at:

Array(SequenceableCollection)>>first

Array(SequenceableCollection)>>anyOne

Array(Collection)>>max

RTAnchorConstraint>>computeExtraDistance

[ :crossings |

element

translateBy:

aSegment vector normal

* (minDistance + self computeExtraDistance) negated ] in RTAnchorConstraint>>moveAwayFromSegment:

BlockClosure>>cull:

Set(Collection)>>ifNotEmpty:

RTAnchorConstraint>>moveAwayFromSegment:

RTAnchorConstraint>>moveElement

RTAnchorConstraint>>update

[ self update ] in RTAnchorConstraint>>build

BlockClosure>>cull:

BlockClosure>>cull:cull:

TRTranslationCallback>>shape:step:

[ :c |

c isTranslationCallback

ifTrue: [ c shape: self step: aStep ] ] in TREllipseShape(TRCallableObject)>>triggerCallbacksForStep:

OrderedCollection>>do:

TREllipseShape(TRCallableObject)>>triggerCallbacksForStep:

TREllipseShape(TRAbstractBoxShape)>>fromRectangle:

TREllipseShape(TRAbstractBoxShape)>>fromRectangle:color:

RTEllipse>>updateFor:trachelShape:

RTEllipse(RTShape)>>updateFor:

RTElement(RTShapedObject)>>update

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

abergel

Re: [Pharo-dev] [Moose-dev] RTAnchorConstraint

There is no other solution? Alex, do you have any idea?

To which problem?

Alexandre

abergel

Re: [Pharo-dev] [Moose-dev] RTAnchorConstraint

In reply to this post by jfabry

Any code I can have to reproduce the problem?

Alexandre

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

On Mar 10, 2016, at 11:25 AM, Johan Fabry <[hidden email]> wrote:

But now there is a new bug RTAnchorConstraint>>computeExtraDistance that I cannot reliably reproduce,

jfabry

Re: [Moose-dev] [Pharo-dev] RTAnchorConstraint

In reply to this post by abergel

On Mar 10, 2016, at 12:08, Alexandre Bergel <[hidden email]> wrote:

There is no other solution? Alex, do you have any idea?

To which problem?

Copy-paste from original mail:

anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-)

| v lbls es e1 e2 a1 a2 layout stepping|

v := RTView new.

lbls := RTLabel new elementsOn: #(#First #Second).

es := RTEllipse new

size: 30;

borderColor: Color black;

elementsOn: #(#source #dest).

addAll: lbls;

addAll: es.

es @ RTDraggable.

es @ RTLabeled.

e1 := RTArrowedLine new

withContinuousCircleAttachPoint;

color: Color black;

edgeFrom: es first to: es second.

v add: e1.

e2 := RTArrowedLine new

withContinuousCircleAttachPoint;

color: Color black;

edgeFrom: es second to: es first.

v add: e2.

a1 := RTAnchorConstraint new.

a1 anchorShape size: 10.

a1 guideLine color: Color red.

element: lbls first;

edge: e1;

balance: 0.2;

minDistance: 10;

build.

(a2 := RTAnchorConstraint new)

element: lbls second;

edge: e2;

balance: 0.2;

minDistance: 10;

build.

layout := RTForceBasedLayout new

charge: -450; length: 100;

doNotUseProgressBar; applyOn: es; yourself.

layout initialLayout: RTSugiyamaLayout new.

stepping := RTSpringLayoutStepping new

view: v; layout: layout;

afterBlock: [ v canvas camera focusOnCenter].

v addAnimation: stepping.

^ v

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Peter Uhnak

Re: [Moose-dev] Re: [Pharo-dev] RTAnchorConstraint

> To which problem?

The problem is that RTSpringLayoutStepping always uses all the elements in the view and ignores what you set to the layout.

This is a problem, because it will try to also layout the anchor, but that will trigger the anchor to fix itself… and we get endless spinning.

On Thu, Mar 10, 2016 at 4:21 PM, Johan Fabry <[hidden email]> wrote:

On Mar 10, 2016, at 12:08, Alexandre Bergel <[hidden email]> wrote:

There is no other solution? Alex, do you have any idea?

To which problem?

Copy-paste from original mail:

anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-)

| v lbls es e1 e2 a1 a2 layout stepping|
v := RTView new.
lbls := RTLabel new elementsOn: #(#First #Second).
es := RTEllipse new
size: 30;
borderColor: Color black;
elementsOn: #(#source #dest).
v
addAll: lbls;
addAll: es.
es @ RTDraggable.
es @ RTLabeled.
e1 := RTArrowedLine new
withContinuousCircleAttachPoint;
color: Color black;
edgeFrom: es first to: es second.
v add: e1.
e2 := RTArrowedLine new
withContinuousCircleAttachPoint;
color: Color black;
edgeFrom: es second to: es first.
v add: e2.
a1 := RTAnchorConstraint new.
a1 anchorShape size: 10.
a1 guideLine color: Color red.
a1
element: lbls first;
edge: e1;
balance: 0.2;
minDistance: 10;
build.
(a2 := RTAnchorConstraint new)
element: lbls second;
edge: e2;
balance: 0.2;
minDistance: 10;
build.
layout := RTForceBasedLayout new
charge: -450; length: 100;
doNotUseProgressBar; applyOn: es; yourself.
layout initialLayout: RTSugiyamaLayout new.
stepping := RTSpringLayoutStepping new
view: v; layout: layout;
afterBlock: [ v canvas camera focusOnCenter].
v addAnimation: stepping.
^ v

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

abergel

Re: [Pharo-dev] [Moose-dev] Re: RTAnchorConstraint

Hi!

Thanks Peter for having spotted the problem. I have fixed it somehow (“somehow” because this is not an ideal solution, but good enough for now).

Try this after having updated Roassal:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

| v lbls es e1 e2 a1 a2 layout stepping|

v := RTView new.

lbls := RTLabel new elementsOn: #(#First #Second).

es := RTEllipse new

size: 30;

borderColor: Color black;

elementsOn: #(#source #dest).

addAll: lbls;

addAll: es.

es @ RTDraggable.

es @ RTLabeled.

e1 := RTArrowedLine new

withContinuousCircleAttachPoint;

color: Color black;

edgeFrom: es first to: es second.

v add: e1.

e2 := RTArrowedLine new

withContinuousCircleAttachPoint;

color: Color black;

edgeFrom: es second to: es first.

v add: e2.

a1 := RTAnchorConstraint new.

a1 anchorShape size: 10.

a1 guideLine color: Color red.

element: lbls first;

edge: e1;

balance: 0.2;

minDistance: 10;

build.

(a2 := RTAnchorConstraint new)

element: lbls second;

edge: e2;

balance: 0.2;

minDistance: 10;

build.

layout := RTForceBasedLayout new

charge: -450; length: 100;

doNotUseProgressBar; applyOn: es; yourself.

layout initialLayout: RTSugiyamaLayout new.

layout nodes: es.

layout start: es.

layout edges: { e1 . e2 }.

stepping := RTSpringLayoutStepping new

view: v; layoutWithoutPreparing: layout;

afterBlock: [ v canvas camera focusOnCenter].

v addAnimation: stepping.

^ v

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Here is a screenshot:

And this is all animated. Cool stuff!

Alexandre

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

On Mar 10, 2016, at 12:42 PM, Peter Uhnák <[hidden email]> wrote:

> To which problem?

The problem is that RTSpringLayoutStepping always uses all the elements in the view and ignores what you set to the layout.

This is a problem, because it will try to also layout the anchor, but that will trigger the anchor to fix itself… and we get endless spinning.

On Thu, Mar 10, 2016 at 4:21 PM, Johan Fabry <[hidden email]> wrote:

On Mar 10, 2016, at 12:08, Alexandre Bergel <[hidden email]> wrote:

There is no other solution? Alex, do you have any idea?

To which problem?

Copy-paste from original mail:

anchor constraints: they do not play well with layouts and animations. Try the code below (adapted from the example to use the layout and animation of LRP ) and you will see that the circles keep spinning around, they never stop. I think it would be better for them to stop ;-)

| v lbls es e1 e2 a1 a2 layout stepping|
v := RTView new.
lbls := RTLabel new elementsOn: #(#First #Second).
es := RTEllipse new
size: 30;
borderColor: Color black;
elementsOn: #(#source #dest).
v
addAll: lbls;
addAll: es.
es @ RTDraggable.
es @ RTLabeled.
e1 := RTArrowedLine new
withContinuousCircleAttachPoint;
color: Color black;
edgeFrom: es first to: es second.
v add: e1.
e2 := RTArrowedLine new
withContinuousCircleAttachPoint;
color: Color black;
edgeFrom: es second to: es first.
v add: e2.
a1 := RTAnchorConstraint new.
a1 anchorShape size: 10.
a1 guideLine color: Color red.
a1
element: lbls first;
edge: e1;
balance: 0.2;
minDistance: 10;
build.
(a2 := RTAnchorConstraint new)
element: lbls second;
edge: e2;
balance: 0.2;
minDistance: 10;
build.
layout := RTForceBasedLayout new
charge: -450; length: 100;
doNotUseProgressBar; applyOn: es; yourself.
layout initialLayout: RTSugiyamaLayout new.
stepping := RTSpringLayoutStepping new
view: v; layout: layout;
afterBlock: [ v canvas camera focusOnCenter].
v addAnimation: stepping.
^ v

---> Save our in-boxes! http://emailcharter.org <---

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

Offray Vladimir Luna Cárdenas-2

Re: Call for action for Roassal

In reply to this post by abergel

Hi,

On the data input front, the main aspect in the workshops is "where the
data comes from?". In the examples of the book, most of it comes from
the Pharo/Moose image itself. Where providing external data sources
(Tweets, medicine info, public spending) and we're creating custom
objects to hold them, but some kind of "generic" spreadsheet for
populating/viewing/editing data sources would be the best addition here.

On the data output front, the HTML exporter generates a great
impression. I think that improving it and including the support for some
small "web applets" with sliders/menus/inbox would be the next step.

Cheers,

Offray

On 24/02/16 03:51, Alexandre Bergel wrote:

> Dear community,
>
> As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question:
>
> What are the 3 aspects you would like to see improved in Roassal?
>
> You can answer publicly or by sending private messages.
>
> Kind regards,
> Alexandre

abergel

Re: [Moose-dev] Re: Call for action for Roassal

In reply to this post by Peter Uhnak

Hi Peter!

Any news about the GraphViz layout?

Cheers,

Alexandre

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

On Feb 24, 2016, at 6:35 AM, Peter Uhnák <[hidden email]> wrote:

On Wed, Feb 24, 2016 at 10:28 AM, Anne Etien <[hidden email]> wrote:
Hi Alexandre,

In a wonderful world, I would like:
- a real graph layout (like in graphviz) that can take into account around hundred nodes and several hundred of edges and place the nodes in order to see something. Currently, I have to use the circle layout and it looks strange.

Unfortunately making real graph layouts is really hard issue… I've wrote my bachelor thesis about this and didn't get very far; it's bit of a nightmare if you don't have good foundations. :'(

In any case, I wrote a simpler layout delegator in Roassal that delegates the layouting to graphviz and it works reasonably well, so I could probably add it to Roassal (you however need graphviz installed and it would add another dependency to Roassal, which I'm not so keen on).

Maybe also OGDF (http://ogdf.net/doku.php) could be used if you are ok with GPL… they have their own graph format so there could be some interaction.

Peter

abergel

Re: [Moose-dev] Re: Call for action for Roassal

I checked the Roassal plugin you defined, but it uses NBMacShell, for which I have no idea what this is :-)

Alexandre

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

On Mar 28, 2016, at 2:41 PM, Alexandre Bergel <[hidden email]> wrote:

Hi Peter!

Any news about the GraphViz layout?

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

On Feb 24, 2016, at 6:35 AM, Peter Uhnák <[hidden email]> wrote:

On Wed, Feb 24, 2016 at 10:28 AM, Anne Etien <[hidden email]> wrote:
Hi Alexandre,

In a wonderful world, I would like:
- a real graph layout (like in graphviz) that can take into account around hundred nodes and several hundred of edges and place the nodes in order to see something. Currently, I have to use the circle layout and it looks strange.

Unfortunately making real graph layouts is really hard issue… I've wrote my bachelor thesis about this and didn't get very far; it's bit of a nightmare if you don't have good foundations. :'(

In any case, I wrote a simpler layout delegator in Roassal that delegates the layouting to graphviz and it works reasonably well, so I could probably add it to Roassal (you however need graphviz installed and it would add another dependency to Roassal, which I'm not so keen on).

Maybe also OGDF (http://ogdf.net/doku.php) could be used if you are ok with GPL… they have their own graph format so there could be some interaction.

Peter

abergel

Re: Call for action for Roassal

In reply to this post by Offray Vladimir Luna Cárdenas-2

Hi Offray!

> On the data input front, the main aspect in the workshops is "where the data comes from?". In the examples of the book, most of it comes from the Pharo/Moose image itself. Where providing external data sources (Tweets, medicine info, public spending) and we're creating custom objects to
> hold them, but some kind of "generic" spreadsheet for populating/viewing/editing data sources would be the best addition here.

Yes, you are right. I have tried to change this. However, I do not always have the data in hand. Help is welcome on this...

> On the data output front, the HTML exporter generates a great impression. I think that improving it and including the support for some small "web applets" with sliders/menus/inbox would be the next step.

This is an interesting point. However, the web world is tough. Sure, we could improve the exporter. But competing against d3 and all its friends is difficult. For example, this morning I’ve heard about http://dimplejs.org . Frankly, it is much simpler to use it than embed a Roassal-generated visualization in an html page.
Having Pharo play a bigger role on the web yes. But the Roassal effort cannot drag it all.
Again, suggestion and help are more than welcome...

Alexandre

>
> On 24/02/16 03:51, Alexandre Bergel wrote:
>> Dear community,
>>
>> As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question:
>>
>> What are the 3 aspects you would like to see improved in Roassal?
>>
>> You can answer publicly or by sending private messages.
>>
>> Kind regards,
>> Alexandre
>
>

Offray Vladimir Luna Cárdenas-2

Re: Call for action for Roassal

Hi Alexandre,

On 28/03/16 12:55, Alexandre Bergel wrote:
> Hi Offray!
>
>> On the data input front, the main aspect in the workshops is "where the data comes from?". In the examples of the book, most of it comes from the Pharo/Moose image itself. Where providing external data sources (Tweets, medicine info, public spending) and we're creating custom objects to
>> hold them, but some kind of "generic" spreadsheet for populating/viewing/editing data sources would be the best addition here.
> Yes, you are right. I have tried to change this. However, I do not always have the data in hand. Help is welcome on this...

And help is coming (sort of... ;-)), because I meant "We're providing
external data sources (Tweets, medicine info, public spending) and we're
creating custom objects to hold them" in grafoscopio. In the "generic
spreadsheet" front we're trying to provide support for SQLite, so we
could try to see what aspects of grafoscopio can be used in tandem with
Roassal.

>> On the data output front, the HTML exporter generates a great impression. I think that improving it and including the support for some small "web applets" with sliders/menus/inbox would be the next step.
> This is an interesting point. However, the web world is tough. Sure, we could improve the exporter. But competing against d3 and all its friends is difficult. For example, this morning I’ve heard about http://dimplejs.org . Frankly, it is much simpler to use it than embed a Roassal-generated visualization in an html page.
> Having Pharo play a bigger role on the web yes. But the Roassal effort cannot drag it all.
> Again, suggestion and help are more than welcome...

I don't know if is possible to use something like and exporter
raphael.js or dimplejs or d3.js... I'm trying something like that for
the pdf world, leveraging the power of pandoc and LaTeX, while keeping
the moldability and interactivity of writing/visualizing inside Pharo.

Anyway, is interesting to consider this future paths and know which are
the perceptions of different actors while using Roassal.

Cheers and thanks as always for this community and what it makes :-),

Offray