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
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@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:
- Distortion when a node is dragged up so that the top of windows stretches up
- Arrows go a bit strange if the child is dragged higher than the parent.
- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-=-=-=-=-=-= 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.
Ok. Let us know if you come up with a nice way to integrate the behavior you wish.
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@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:
- Distortion when a node is dragged up so that the top of windows stretches up
- Arrows go a bit strange if the child is dragged higher than the parent.
- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@openInWorld.com wrote:
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@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:
- Distortion when a node is dragged up so that the top of windows stretches up
- Arrows go a bit strange if the child is dragged higher than the parent.
- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
No pb :-)
Alexandre
On Aug 29, 2012, at 2:25 PM, Ben Coman btc@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:
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@openInWorld.com wrote:
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
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:
- Distortion when a node is dragged up so that the top of windows stretches up
- Arrows go a bit strange if the child is dragged higher than the parent.
- 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list
Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Alexandre Bergel -
Ben Coman -
Ben Coman