Smalltalk › Frameworks & Tools › Moose

Call for action for Roassal

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

38 messages Options

jfabry

Re: Call for action for Roassal

Better late than never :-) (working on the holidays backlog)

I only have one request: better positioning on labels of nodes and edges. For example see the image: three of the four labels are badly positioned because the bounding box of their text is intersected by one or more edges.

I know that to solve this generally is hard, but for simple cases like this it should be possible.

Ah, and it should work well with animations and dragging of course ;-)

On Feb 24, 2016, at 05:51, Alexandre Bergel <[hidden email]> 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
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

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

abergel

Re: Call for action for Roassal

Thanks!

Alexandre

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

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

Better late than never :-) (working on the holidays backlog)

I only have one request: better positioning on labels of nodes and edges. For example see the image: three of the four labels are badly positioned because the bounding box of their text is intersected by one or more edges.

<Screen Shot 2016-03-07 at 10.31.24.png>
I know that to solve this generally is hard, but for simple cases like this it should be possible.

Ah, and it should work well with animations and dragging of course ;-)

On Feb 24, 2016, at 05:51, Alexandre Bergel <[hidden email]> 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
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

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

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

Peter Uhnak

Re: Call for action for Roassal

In reply to this post by jfabry

Hi Johan,

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

I've been using it for my class diagrams where it works quite well, however class diagrams are usually orthogonal-ish, which makes it a bit nicer.

The Anchor will avoid intersecting it's own line, and one of the end shapes (it should both but apparently I have a bug there...).

It doesn't look at other lines, however you can specify on which side it should be.

(You can also put the node label inside the circle with `el @ (RTLabelled new center)` but you probably know that.)

I have also a global edge labeling layout which produces good placement… but it's slow as hell… I need to write a fast flow alogrithm…

Also the Anchor currently doesn't work with self-edges. On the other hand Roassal doesn't have self-edges yet so it shouldn't be a problem. :)

Peter

On Mon, Mar 7, 2016 at 2:34 PM, Johan Fabry <[hidden email]> wrote:

Better late than never :-) (working on the holidays backlog)

I only have one request: better positioning on labels of nodes and edges. For example see the image: three of the four labels are badly positioned because the bounding box of their text is intersected by one or more edges.

I know that to solve this generally is hard, but for simple cases like this it should be possible.

Ah, and it should work well with animations and dragging of course ;-)

On Feb 24, 2016, at 05:51, Alexandre Bergel <[hidden email]> 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
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

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

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

jfabry

Re: [Pharo-users] Re: Call for action for Roassal

Excellent, thanks a lot! I will take a look at that tomorrow.

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

Hi Johan,

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

I've been using it for my class diagrams where it works quite well, however class diagrams are usually orthogonal-ish, which makes it a bit nicer.
<uml.png>

The Anchor will avoid intersecting it's own line, and one of the end shapes (it should both but apparently I have a bug there...).
It doesn't look at other lines, however you can specify on which side it should be.

(You can also put the node label inside the circle with `el @ (RTLabelled new center)` but you probably know that.)
<anchor.png>

I have also a global edge labeling layout which produces good placement… but it's slow as hell… I need to write a fast flow alogrithm…

Also the Anchor currently doesn't work with self-edges. On the other hand Roassal doesn't have self-edges yet so it shouldn't be a problem. :)

Peter

On Mon, Mar 7, 2016 at 2:34 PM, Johan Fabry <[hidden email]> wrote:

Better late than never :-) (working on the holidays backlog)

I only have one request: better positioning on labels of nodes and edges. For example see the image: three of the four labels are badly positioned because the bounding box of their text is intersected by one or more edges.

<Screen Shot 2016-03-07 at 10.31.24.png>
I know that to solve this generally is hard, but for simple cases like this it should be possible.

Ah, and it should work well with animations and dragging of course ;-)

On Feb 24, 2016, at 05:51, Alexandre Bergel <[hidden email]> 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
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

_______________________________________________
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

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

jfabry

Re: [Pharo-users] Re: Call for action for Roassal

In reply to this post by Peter Uhnak

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

jfabry

Re: [Pharo-users] 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

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

Peter Uhnak

Re: [Pharo-users] 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

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

Peter Uhnak

Re: [Pharo-users] Call for action for Roassal

In reply to this post by abergel

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/

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

Ben Coman

Re: [Pharo-users] Call for action for Roassal

On Thu, Mar 10, 2016 at 8:31 AM, Peter Uhnák <[hidden email]> wrote:

I wonder if withShorterVerticalAttachPoint would look nice if it provided a short vertical stub off the shape that an orthogonal line could connect to.

cheers -ben

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

Peter Uhnak

Re: [Pharo-users] Call for action for Roassal

I wonder if withShorterVerticalAttachPoint would look nice if it provided a short vertical stub off the shape that an orthogonal line could connect to.

That's line's responsibility. We have RTMultiLine for that. Also the situation is same for withShorterHorizontalAttachPoint, you just don't see it (because the line is horizontal).

For example:

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

|v es e1 e2 offset|

v := RTView new.

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

es @ RTDraggable.

v addAll: es.

es second translateBy: 300 @ 25.

es third translateBy: 25 @ 300.

e1 := RTMultiLine new

color: Color black;

withShorterHorizontalAttachPoint;

orthoHorizontal;

edgeFrom: es first to: es second.

e1 model: #withShorterHorizontalAttachPoint.

v add: e1.

e1 @ (RTLabelled new color: Color black).

e1 := RTMultiLine new

color: Color black;

withShorterVerticalAttachPoint;

orthoVertical;

edgeFrom: es first to: es third.

e1 model: #withShorterVerticalAttachPoint.

v add: e1.

e1 @ (RTLabelled new color: Color black).

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

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

Ben Coman

Re: [Pharo-users] Call for action for Roassal

On Thu, Mar 10, 2016 at 9:19 AM, Peter Uhnák <[hidden email]> wrote:

I wonder if withShorterVerticalAttachPoint would look nice if it provided a short vertical stub off the shape that an orthogonal line could connect to.

That's line's responsibility. We have RTMultiLine for that. Also the situation is same for withShorterHorizontalAttachPoint, you just don't see it (because the line is horizontal).

For example:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|v es e1 e2 offset|
v := RTView new.

es := RTBox new borderColor: Color black; size: 50; elementsOn: #(a b c).
es @ RTDraggable.
v addAll: es.

es second translateBy: 300 @ 25.
es third translateBy: 25 @ 300.

e1 := RTMultiLine new
color: Color black;
withShorterHorizontalAttachPoint;
orthoHorizontal;
edgeFrom: es first to: es second.
e1 model: #withShorterHorizontalAttachPoint.
v add: e1.
e1 @ (RTLabelled new color: Color black).

e1 := RTMultiLine new
color: Color black;
withShorterVerticalAttachPoint;
orthoVertical;
edgeFrom: es first to: es third.
e1 model: #withShorterVerticalAttachPoint.
v add: e1.
e1 @ (RTLabelled new color: Color black).

I was thinking an ortho line combined with a vertical stub attachment point might give you something like this...

cheers -ben

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

unnamed2.png (18K) Download Attachment

Peter Uhnak

Re: [Pharo-users] Call for action for Roassal

I was thinking an ortho line combined with a vertical stub attachment point might give you something like this...

Yes, this sounds interesting. :)

Peter

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

jfabry

Re: [Pharo-users] 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

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

abergel

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

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

To which problem?

Alexandre

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

abergel

Re: [Pharo-dev] [Pharo-users] 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,

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

jfabry

Re: [Pharo-dev] [Pharo-users] 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

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

Peter Uhnak

Re: [Pharo-dev] [Pharo-users] 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

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

abergel

Re: [Pharo-dev] Re: [Pharo-users] 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

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