8 Aug
2012
8 Aug
'12
6:05 p.m.
With the Ortho layouts in Mondrian and now Roassal, I find that it can
get a bit messy when moving nodes around when each node pair has its
middle line segment spaced at 50% from each end. I have thought for a
while that it might even better if the middle segment could be shared
among child nodes. So I've done a basic implementation this, and there
are a lot of rough edges, but I wanted to share this before going any
further to check if this approach is reasonable, or if there is a better
way to proceed.
A few of the things that need to be sorted are:
1. Distortion when a node is dragged up so that the top of windows
stretches up
2. Arrows go a bit strange if the child is dragged higher than the parent.
3. The horizontal mid-segments need to be offset, otherwise the join
together when a child node is dragged to the far side.
Attached is an image showing the two methods side by side, and also the mcz.
cheer -ben
8 Aug
8 Aug
8:45 p.m.
Hi Ben!
Thanks again for pushing in that direction.
Here is the code culprit for the original behavior:
-=-=-=-=-=-=
ROOrthoVerticalLineShape>>drawOn:for:
...
midy := ((edgeBound corner y - edgeBound origin y) / 2) asInteger + edgeBound origin y.
...
-=-=-=-=-=-=
I think the "/ 2" should be replaced by "* f" where f having should be
a float 0.0<= f <= 1.0.
This float should then be parametrizable obviously, with 0.5 as default value.
Actually, this code should be in a utility method that is tested.
Does it make sense to you?
Cheers,
Alexandre
NB: I am currently under various deadline. In two weeks I will be freer, meaning I will
look at the treemap layout of Dennis and fixes some more bugs.
On Aug 8, 2012, at 12:05 PM, Ben Coman <btc(a)openInWorld.com> wrote:
With the Ortho layouts in Mondrian and now Roassal, I
find that it can get a bit messy when moving nodes around when each node pair has its
middle line segment spaced at 50% from each end. I have thought for a while that it might
even better if the middle segment could be shared among child nodes. So I've done a
basic implementation this, and there are a lot of rough edges, but I wanted to share this
before going any further to check if this approach is reasonable, or if there is a better
way to proceed.
A few of the things that need to be sorted are:
1. Distortion when a node is dragged up so that the top of windows stretches up
2. Arrows go a bit strange if the child is dragged higher than the parent.
3. The horizontal mid-segments need to be offset, otherwise the join together when a
child node is dragged to the far side.
Attached is an image showing the two methods side by side, and also the mcz.
cheer -ben
<ProposedOrthoBehvaiour.png><Roassal-BenComan.273.mcz>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2:42 p.m.
-=-=-=-=-=-=
ROOrthoVerticalLineShape>>drawOn:for:
...
midy := ((edgeBound corner y - edgeBound origin y) / 2) asInteger + edgeBound origin y.
...
-=-=-=-=-=-=
I think the "/ 2" should be replaced by "* f" where f having should
be a float 0.0<= f <= 1.0.
This float should then be parametrizable obviously, with 0.5 as default value.
Dividing by a variable rather than a constant is good for its own reasons, but
doesn't quite achieve what I desired. As the distance between the From and To nodes
increases, the horizontal middle line segment still moves away from overlapping all the
others, which is the key part I want. Just woke up with the idea that rather than
storing the midy point, I need to store the relative distance between the From node and
the midy point. Got to go to work now. I'll have another try this evening. Not quite sure what you mean by implementing a utility
method. I am guessing perhaps a method #fixedFromDistance that is sent to
ROOrthoVerticalLineShape to turn on this behaviour.
I just mean to have the code clean and tested.
Cheers,
Alexandre
Does it make sense to you?
Cheers,
Alexandre
NB: I am currently under various deadline. In two weeks I will be freer, meaning I will
look at the treemap layout of Dennis and fixes some more bugs.
On Aug 8, 2012, at 12:05 PM, Ben Coman
<btc(a)openInWorld.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev With the Ortho layouts in Mondrian and now
Roassal, I find that it can get a bit messy when moving nodes around when each node pair
has its middle line segment spaced at 50% from each end. I have thought for a while that
it might even better if the middle segment could be shared among child nodes. So I've
done a basic implementation this, and there are a lot of rough edges, but I wanted to
share this before going any further to check if this approach is reasonable, or if there
is a better way to proceed.
A few of the things that need to be sorted are:
1. Distortion when a node is dragged up so that the top of windows stretches up
2. Arrows go a bit strange if the child is dragged higher than the parent.
3. The horizontal mid-segments need to be offset, otherwise the join together when a
child node is dragged to the far side.
Attached is an image showing the two methods side by side, and also the mcz.
cheer -ben
<ProposedOrthoBehvaiour.png><Roassal-BenComan.273.mcz>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
21 Aug
21 Aug
2:58 p.m.
Hi Ben,
Is there anything new on this side?
Is there a particularization of orthoVerticalLine you should like to see in the
distribution?
Cheers,
Alexandre
On Aug 8, 2012, at 6:15 PM, Ben Coman <btc(a)openInWorld.com> wrote:
Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Ben!
Thanks again for pushing in that direction.
Here is the code culprit for the original behavior:
-=-=-=-=-=-=
ROOrthoVerticalLineShape>>drawOn:for:
...
midy := ((edgeBound corner y - edgeBound origin y) / 2) asInteger + edgeBound origin y.
...
-=-=-=-=-=-=
I think the "/ 2" should be replaced by "* f" where f having should
be a float 0.0<= f <= 1.0.
This float should then be parametrizable obviously, with 0.5 as default value.
Dividing by a variable rather than a constant is good for its own reasons, but
doesn't quite achieve what I desired. As the distance between the From and To nodes
increases, the horizontal middle line segment still moves away from overlapping all the
others, which is the key part I want. Just woke up with the idea that rather than
storing the midy point, I need to store the relative distance between the From node and
the midy point. Got to go to work now. I'll have another try this evening.
Actually, this code should be in a utility method
that is tested.
Not quite sure what you mean by implementing a utility method. I am guessing
perhaps a method #fixedFromDistance that is sent to ROOrthoVerticalLineShape to turn on
this behaviour.
Does it make sense to you?
Cheers,
Alexandre
NB: I am currently under various deadline. In two weeks I will be freer, meaning I will
look at the treemap layout of Dennis and fixes some more bugs.
On Aug 8, 2012, at 12:05 PM, Ben Coman
<btc(a)openInWorld.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev With the Ortho layouts in Mondrian and now
Roassal, I find that it can get a bit messy when moving nodes around when each node pair
has its middle line segment spaced at 50% from each end. I have thought for a while that
it might even better if the middle segment could be shared among child nodes. So I've
done a basic implementation this, and there are a lot of rough edges, but I wanted to
share this before going any further to check if this approach is reasonable, or if there
is a better way to proceed.
A few of the things that need to be sorted are:
1. Distortion when a node is dragged up so that the top of windows stretches up
2. Arrows go a bit strange if the child is dragged higher than the parent.
3. The horizontal mid-segments need to be offset, otherwise the join together when a
child node is dragged to the far side.
Attached is an image showing the two methods side by side, and also the mcz.
cheer -ben
<ProposedOrthoBehvaiour.png><Roassal-BenComan.273.mcz>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:27 p.m.
No pb :-)
Alexandre
On Aug 29, 2012, at 2:25 PM, Ben Coman <btc(a)openInWorld.com> wrote:
Hi Alexandre,
Thanks for your interest. I played with a few ideas but couldn't get it too my
liking without more effort than I can afford right now. I enjoyed digging in - but it is
providing too easy a distraction from some other areas I should be concentrating on for my
masters project, which may also help flesh out my Ortho requirements. I will work with
the existing behaviour for now and return to this later on.
cheers -ben
Alexandre Bergel wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Ben,
Is there anything new on this side?
Is there a particularization of orthoVerticalLine you should like to see in the
distribution?
Cheers,
Alexandre
On Aug 8, 2012, at 6:15 PM, Ben Coman
<btc(a)openInWorld.com>
wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Alexandre Bergel wrote:
Hi Ben!
Thanks again for pushing in that direction.
Here is the code culprit for the original behavior:
-=-=-=-=-=-=
ROOrthoVerticalLineShape>>drawOn:for:
...
midy := ((edgeBound corner y - edgeBound origin y) / 2) asInteger + edgeBound origin y.
...
-=-=-=-=-=-=
I think the "/ 2" should be replaced by "* f" where f having should
be a float 0.0<= f <= 1.0.
This float should then be parametrizable obviously, with 0.5 as default value.
Dividing by a variable rather than a constant is good for its own reasons, but
doesn't quite achieve what I desired. As the distance between the From and To nodes
increases, the horizontal middle line segment still moves away from overlapping all the
others, which is the key part I want. Just woke up with the idea that rather than
storing the midy point, I need to store the relative distance between the From node and
the midy point. Got to go to work now. I'll have another try this evening.
Actually, this code should be in a utility method
that is tested.
Not quite sure what you mean by implementing a utility method. I am guessing
perhaps a method #fixedFromDistance that is sent to ROOrthoVerticalLineShape to turn on
this behaviour.
Does it make sense to you?
Cheers,
Alexandre
NB: I am currently under various deadline. In two weeks I will be freer, meaning I will
look at the treemap layout of Dennis and fixes some more bugs.
On Aug 8, 2012, at 12:05 PM, Ben Coman
<btc(a)openInWorld.com>
wrote:
> With the Ortho layouts in Mondrian and now Roassal, I find that it can get a bit
messy when moving nodes around when each node pair has its middle line segment spaced at
50% from each end. I have thought for a while that it might even better if the middle
segment could be shared among child nodes. So I've done a basic implementation this,
and there are a lot of rough edges, but I wanted to share this before going any further to
check if this approach is reasonable, or if there is a better way to proceed.
>
> A few of the things that need to be sorted are:
> 1. Distortion when a node is dragged up so that the top of windows stretches up
> 2. Arrows go a bit strange if the child is dragged higher than the parent.
> 3. The horizontal mid-segments need to be offset, otherwise the join together when a
child node is dragged to the far side.
>
> Attached is an image showing the two methods side by side, and also the mcz.
>
> cheer -ben
>
<ProposedOrthoBehvaiour.png><Roassal-BenComan.273.mcz>_______________________________________________
> Moose-dev mailing list
>
>
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
>
>
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4512
days inactive
4533
days old
6 comments
3 participants
participants (3)
-
Alexandre Bergel -
Ben Coman -
Ben Coman