You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I often create schematic diagrams about data structures and algorithms. But there are two key limitations which keep them from being as clear as they should be:
I want to show that ds1 is related to the first syntax line with a clear connection, and the same for ds2 to the second syntax line.
If the lines were routing orthogonally perpendicular to the nearest shape crossing, then the connection point would be obvious.
Otherwise, if I were able to specify that the connection should terminate at the middle-left of the target element, that might be good enough, even with non-orthogonal connection routing.
So, to solve this cleanly, it seems that both of these things might need to be supported:
Allow a line style to be set to orthogonal, optionally setting a rule crossing the closest non-endpoint boundary perpendicularly.
Allow pseudo ports to be defined for an element which determine a spatial connection point.
A pseudo-port would simply be a simple scheme which names positions on an element at the boundary of its shape.
You could allow a relative polar-coordinate, such as "56°", or "56 d" or "56 degrees", to indicate the radial position, and optionally a second part which would be a relative distance from center, with 1.0 meaning the outer rendering boundary, but allowing smaller or larger values.
You could allow an even subdivision of all possible polar coordinates with some "slices of pie" quantity, and maybe an optional distance offset as above. This could also have a base offset for rotating the set of ports as desired.
You could allow for a set of pseudo-port names to be assigned, assuming the user weren't happy with the default of simple numerical indices.
This would allow for globbing to be used to ascribe a set of default pseudo-port configurations to any element with a high degree of flexibility.
The idea of a visible "port" element as in #605 would suffice if it could be made invisible. Even 605 as sketched would be a better alternative than not having either option.
The text was updated successfully, but these errors were encountered:
I often create schematic diagrams about data structures and algorithms. But there are two key limitations which keep them from being as clear as they should be:
Consider this example.
I want to show that ds1 is related to the first syntax line with a clear connection, and the same for ds2 to the second syntax line.
If the lines were routing orthogonally perpendicular to the nearest shape crossing, then the connection point would be obvious.
Otherwise, if I were able to specify that the connection should terminate at the middle-left of the target element, that might be good enough, even with non-orthogonal connection routing.
So, to solve this cleanly, it seems that both of these things might need to be supported:
A pseudo-port would simply be a simple scheme which names positions on an element at the boundary of its shape.
This would allow for globbing to be used to ascribe a set of default pseudo-port configurations to any element with a high degree of flexibility.
The idea of a visible "port" element as in #605 would suffice if it could be made invisible. Even 605 as sketched would be a better alternative than not having either option.
The text was updated successfully, but these errors were encountered: