Roassal proposed modified Ortho behaviour
Locked
 
|
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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev  ProposedOrthoBehvaiour.png (18K) Download Attachment Roassal-BenComan.273.mcz (273K) Download Attachment |
|
|
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 <[hidden email]> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Alexandre Bergel wrote:
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.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. 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.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 [hidden email] 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] 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 >> <[hidden email]> >> 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 >>> >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >> >> >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Ben Coman
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 <[hidden email]> 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 >> <[hidden email]> >> 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 >>> >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >> >> >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 [hidden email] wrote: _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
No pb :-)
Alexandre On Aug 29, 2012, at 2:25 PM, Ben Coman <[hidden email]> 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 >> <[hidden email]> >> 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 >>>> >>>> <[hidden email]> >>>> >>>> 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 >>>>> >>>>> >>>>> [hidden email] >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Moose-dev mailing list >>> >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >> >> >> > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |