This repository has been archived by the owner. It is now read-only.

Keep line endings outside of component boundaries #228

Closed
smithdtyler opened this Issue Oct 2, 2017 · 24 comments

Comments

Projects
None yet
3 participants
@smithdtyler

smithdtyler commented Oct 2, 2017

Line endings should be kept entirely outside of the component to which they connect. Allowing line endings to obscure the edge of their component (instead of merely touching it) make for a confusing and less visually pleasing diagram.

The meaning is also less clear when the arrow is allowed inside of the component boundary. For example, in the snapshot below it's hard to tell whether the connection is incoming or outgoing.

screen shot 2017-10-02 at 4 34 27 pm

Moving the port to a different side makes it clearer, but the visual collision still looks rough.

screen shot 2017-10-02 at 4 37 26 pm

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 3, 2017

Contributor

I'm not sure how practical it will be in the near term to prevent this. However, improved layout would at least provide a better default.

What is it about the second image that looks rough?

Contributor

philip-alldredge commented Oct 3, 2017

I'm not sure how practical it will be in the near term to prevent this. However, improved layout would at least provide a better default.

What is it about the second image that looks rough?

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 3, 2017

The simplest approach would be to position the line ending icon offset a little bit from the boundary of the component - perhaps a 10px padding around the entire component?

In the second image, the collision between the port icon and the boundary of the component is not aesthetically pleasing.

screen shot 2017-10-03 at 9 18 13 am

smithdtyler commented Oct 3, 2017

The simplest approach would be to position the line ending icon offset a little bit from the boundary of the component - perhaps a 10px padding around the entire component?

In the second image, the collision between the port icon and the boundary of the component is not aesthetically pleasing.

screen shot 2017-10-03 at 9 18 13 am

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 3, 2017

Contributor

Can you make a mockup of what you mean by the 10px padding? Are you saying that the port would be outside the subcomponent?

In the standard the ports are positioned in the middle of the subcomponent boundary such that connections do not have to cross the subcomponent boundary. For example flows and connections originating inside a subcomponent would connect graphically to the portion inside the subcomponent and connections outside the subcomponent would connect graphically to the portion of the port on the outside of the sbucomponent.

However, that isn't the case in the editor because of difficulties with child diagram elements extending past the boundary of their parents. We have found workarounds in a few cases but we never applies to features.

Contributor

philip-alldredge commented Oct 3, 2017

Can you make a mockup of what you mean by the 10px padding? Are you saying that the port would be outside the subcomponent?

In the standard the ports are positioned in the middle of the subcomponent boundary such that connections do not have to cross the subcomponent boundary. For example flows and connections originating inside a subcomponent would connect graphically to the portion inside the subcomponent and connections outside the subcomponent would connect graphically to the portion of the port on the outside of the sbucomponent.

However, that isn't the case in the editor because of difficulties with child diagram elements extending past the boundary of their parents. We have found workarounds in a few cases but we never applies to features.

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 3, 2017

Can you make a mockup of what you mean by the 10px padding? Are you saying that the port would be outside the subcomponent?

screen shot 2017-10-03 at 10 46 46 am

In the standard the ports are positioned in the middle of the subcomponent boundary such that connections do not have to cross the subcomponent boundary. For example flows and connections originating inside a subcomponent would connect graphically to the portion inside the subcomponent and connections outside the subcomponent would connect graphically to the portion of the port on the outside of the subcomponent.

I can see how this makes logical sense (and that you're bound by the standard), the problem is that as implemented it doesn't make a diagram that I would want to present to a customer.

smithdtyler commented Oct 3, 2017

Can you make a mockup of what you mean by the 10px padding? Are you saying that the port would be outside the subcomponent?

screen shot 2017-10-03 at 10 46 46 am

In the standard the ports are positioned in the middle of the subcomponent boundary such that connections do not have to cross the subcomponent boundary. For example flows and connections originating inside a subcomponent would connect graphically to the portion inside the subcomponent and connections outside the subcomponent would connect graphically to the portion of the port on the outside of the subcomponent.

I can see how this makes logical sense (and that you're bound by the standard), the problem is that as implemented it doesn't make a diagram that I would want to present to a customer.

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 3, 2017

Contributor

Okay. Thanks for clarifying. One of the problems with positioning the features outside the port is that output ports such the one shown will often have flows or connections from inside that subcomponent. I doubt such a representation would look nice either.

Which features are the most unsightly in your opinion? Are event-data ports your primary concern or are others as well? I believe SysML shows most ports as a box which is centered on the boundary. Perhaps we could enclose the port in a solid box.

Contributor

philip-alldredge commented Oct 3, 2017

Okay. Thanks for clarifying. One of the problems with positioning the features outside the port is that output ports such the one shown will often have flows or connections from inside that subcomponent. I doubt such a representation would look nice either.

Which features are the most unsightly in your opinion? Are event-data ports your primary concern or are others as well? I believe SysML shows most ports as a box which is centered on the boundary. Perhaps we could enclose the port in a solid box.

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 3, 2017

I believe SysML shows most ports as a box which is centered on the boundary. Perhaps we could enclose the port in a solid box.

This might help, but it would also add more content to the diagram, which could increase visual clutter.

Which features are the most unsightly in your opinion? Are event-data ports your primary concern or are others as well?

Connections and ports are my biggest concerns. I've made tickets for some of these, but here's a rough breakdown my my priorities (highest first):

  1. Overlap: My biggest overall concern is when objects overlap. I don't want lines crossing over my components, labels obscured by lines, or components colliding with one another. Event-data ports are a prime example of this (since the Port icon overlaps the component boundary).

  2. Line and Icon Orientation: Connections and their ports should flow visually. Right now the "arrow" shown for an event-data port doesn't necessarily line up with the connection "line". Rotating the event-port icon would help address this problem, as would fixing the end of the connection to the "rear" of the event-port icon for incoming ports.

screen shot 2017-10-03 at 11 12 30 am

screen shot 2017-10-03 at 11 23 36 am

Similarly, the "midpoint" arrow can also get stuck in a weird spot. I'd like to be able to position this arbitrarily along the connection line.

screen shot 2017-10-03 at 11 13 10 am

  1. Layout and Organization: Right now I had to manually move event-data ports immediately after adding them because the default display location of the port is often on the opposite side of its parent from where I want it. Note that the example below is doubly confusing because the event-port arrow icon and the connection midpoint icon are pointing in opposite directions.

screen shot 2017-10-03 at 11 22 52 am

smithdtyler commented Oct 3, 2017

I believe SysML shows most ports as a box which is centered on the boundary. Perhaps we could enclose the port in a solid box.

This might help, but it would also add more content to the diagram, which could increase visual clutter.

Which features are the most unsightly in your opinion? Are event-data ports your primary concern or are others as well?

Connections and ports are my biggest concerns. I've made tickets for some of these, but here's a rough breakdown my my priorities (highest first):

  1. Overlap: My biggest overall concern is when objects overlap. I don't want lines crossing over my components, labels obscured by lines, or components colliding with one another. Event-data ports are a prime example of this (since the Port icon overlaps the component boundary).

  2. Line and Icon Orientation: Connections and their ports should flow visually. Right now the "arrow" shown for an event-data port doesn't necessarily line up with the connection "line". Rotating the event-port icon would help address this problem, as would fixing the end of the connection to the "rear" of the event-port icon for incoming ports.

screen shot 2017-10-03 at 11 12 30 am

screen shot 2017-10-03 at 11 23 36 am

Similarly, the "midpoint" arrow can also get stuck in a weird spot. I'd like to be able to position this arbitrarily along the connection line.

screen shot 2017-10-03 at 11 13 10 am

  1. Layout and Organization: Right now I had to manually move event-data ports immediately after adding them because the default display location of the port is often on the opposite side of its parent from where I want it. Note that the example below is doubly confusing because the event-port arrow icon and the connection midpoint icon are pointing in opposite directions.

screen shot 2017-10-03 at 11 22 52 am

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 3, 2017

I believe SysML shows most ports as a box which is centered on the boundary. Perhaps we could enclose the port in a solid box.

Like this?

screen shot 2017-10-03 at 10 46 46 am_sysml

smithdtyler commented Oct 3, 2017

I believe SysML shows most ports as a box which is centered on the boundary. Perhaps we could enclose the port in a solid box.

Like this?

screen shot 2017-10-03 at 10 46 46 am_sysml

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 3, 2017

Contributor

Overlap: My biggest overall concern is when objects overlap. I don't want lines crossing over my components, labels obscured by lines, or components colliding with one another. Event-data ports are a prime example of this (since the Port icon overlaps the component boundary).

Agreed. However, ports only overlap the graphic of the sub-component for sub-components which aren't represented by rectangles. In other cases they are placed on the inside. This is opposite from what you propose but with case has issues because there will be lines drawn to connections from both side of the port.

Line and Icon Orientation: Connections and their ports should flow visually. Right now the "arrow" shown for an event-data port doesn't necessarily line up with the connection "line". Rotating the event-port icon would help address this problem, as would fixing the end of the connection to the "rear" of the event-port icon for incoming ports.

Rotating the event port icon isn't a viable solution. Since there can be many graphical connections to the same port. Some of those would be coming from inside and some of those would be coming from outside.

Similarly, the "midpoint" arrow can also get stuck in a weird spot. I'd like to be able to position this arbitrarily along the connection line.

Unfortunately that won't be allowed in the near future. I would like to at least fix the graphic so it isn't placed off the line.

Layout and Organization: Right now I had to manually move event-data ports immediately after adding them because the default display location of the port is often on the opposite side of its parent from where I want it. Note that the example below is doubly confusing because the event-port arrow icon and the connection midpoint icon are pointing in opposite directions.

I agree that the default layout of ports need to be improved. This is part of the ongoing layout improvements. Although I'm optimistic about the performance of the new layout system when laying out of the entire diagram, incremental layout may still be a problem.

Like this?

Yes, except the line would connect to the box and not the inside of the event-data port graphic. The contents of the box would indicate the type of port it is.

Example Systems

example

Example Processes

example_process

Contributor

philip-alldredge commented Oct 3, 2017

Overlap: My biggest overall concern is when objects overlap. I don't want lines crossing over my components, labels obscured by lines, or components colliding with one another. Event-data ports are a prime example of this (since the Port icon overlaps the component boundary).

Agreed. However, ports only overlap the graphic of the sub-component for sub-components which aren't represented by rectangles. In other cases they are placed on the inside. This is opposite from what you propose but with case has issues because there will be lines drawn to connections from both side of the port.

Line and Icon Orientation: Connections and their ports should flow visually. Right now the "arrow" shown for an event-data port doesn't necessarily line up with the connection "line". Rotating the event-port icon would help address this problem, as would fixing the end of the connection to the "rear" of the event-port icon for incoming ports.

Rotating the event port icon isn't a viable solution. Since there can be many graphical connections to the same port. Some of those would be coming from inside and some of those would be coming from outside.

Similarly, the "midpoint" arrow can also get stuck in a weird spot. I'd like to be able to position this arbitrarily along the connection line.

Unfortunately that won't be allowed in the near future. I would like to at least fix the graphic so it isn't placed off the line.

Layout and Organization: Right now I had to manually move event-data ports immediately after adding them because the default display location of the port is often on the opposite side of its parent from where I want it. Note that the example below is doubly confusing because the event-port arrow icon and the connection midpoint icon are pointing in opposite directions.

I agree that the default layout of ports need to be improved. This is part of the ongoing layout improvements. Although I'm optimistic about the performance of the new layout system when laying out of the entire diagram, incremental layout may still be a problem.

Like this?

Yes, except the line would connect to the box and not the inside of the event-data port graphic. The contents of the box would indicate the type of port it is.

Example Systems

example

Example Processes

example_process

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 3, 2017

I like the look of the input and output ports in the examples you provide.

A nit: can you edit the above comment to render the quotes and responses separately?

smithdtyler commented Oct 3, 2017

I like the look of the input and output ports in the examples you provide.

A nit: can you edit the above comment to render the quotes and responses separately?

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 3, 2017

Line and Icon Orientation: Connections and their ports should flow visually. Right now the "arrow" shown for an event-data port doesn't necessarily line up with the connection "line". Rotating the event-port icon would help address this problem, as would fixing the end of the connection to the "rear" of the event-port icon for incoming ports.

Rotating the event port icon isn't a viable solution. Since there can be many graphical connections to the same port. Some of those would be coming from inside and some of those would be coming from outside.

OK, the box seems like a good solution then.

Similarly, the "midpoint" arrow can also get stuck in a weird spot. I'd like to be able to position this arbitrarily along the connection line.

Unfortunately that won't be allowed in the near future. I would like to at least fix the graphic so it isn't placed off the line.

Works for me.

smithdtyler commented Oct 3, 2017

Line and Icon Orientation: Connections and their ports should flow visually. Right now the "arrow" shown for an event-data port doesn't necessarily line up with the connection "line". Rotating the event-port icon would help address this problem, as would fixing the end of the connection to the "rear" of the event-port icon for incoming ports.

Rotating the event port icon isn't a viable solution. Since there can be many graphical connections to the same port. Some of those would be coming from inside and some of those would be coming from outside.

OK, the box seems like a good solution then.

Similarly, the "midpoint" arrow can also get stuck in a weird spot. I'd like to be able to position this arbitrarily along the connection line.

Unfortunately that won't be allowed in the near future. I would like to at least fix the graphic so it isn't placed off the line.

Works for me.

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 3, 2017

Contributor

I fixed the comment. I always forget that I need to add additional newlines.

I'm not sure how soon I can fix the midpoint arrow. It may have to be after GEF5 migration. I don't want to end up spending too many resources at this time on code that is going to be reworked.

I plan to bring a few more people into the discussion regarding the feature graphics before wrapping the features in boxes.

Contributor

philip-alldredge commented Oct 3, 2017

I fixed the comment. I always forget that I need to add additional newlines.

I'm not sure how soon I can fix the midpoint arrow. It may have to be after GEF5 migration. I don't want to end up spending too many resources at this time on code that is going to be reworked.

I plan to bring a few more people into the discussion regarding the feature graphics before wrapping the features in boxes.

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 3, 2017

I'm not sure how soon I can fix the midpoint arrow. It may have to be after GEF5 migration. I don't want to end up spending too many resources at this time on code that is going to be reworked.

Makes sense, I wouldn't want time spent on code that will soon be discarded.

I plan to bring a few more people into the discussion regarding the feature graphics before wrapping the features in boxes.

Feel free to schedule a conference call if that's easier than github.

smithdtyler commented Oct 3, 2017

I'm not sure how soon I can fix the midpoint arrow. It may have to be after GEF5 migration. I don't want to end up spending too many resources at this time on code that is going to be reworked.

Makes sense, I wouldn't want time spent on code that will soon be discarded.

I plan to bring a few more people into the discussion regarding the feature graphics before wrapping the features in boxes.

Feel free to schedule a conference call if that's easier than github.

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 3, 2017

Contributor

@reteprelief @lwrage @RyanMcilnay Do you have any thoughts on this? I wanted to bring this up for discussion since this is a significant change and a departure from the graphical examples in the standard.

To summarize, I suggest we make the following suggestions to the feature graphics in the graphical editor:

  • Make them the same size. This prevents the size of the features changing when the type of feature changes. Resizing a feature could result in the movement of adjacent features which could cause the user frustration.
  • Wrap features in boxes. This would be similar to how SysML represented ports. This would avoid confusion regarding the feature to which the connection is connected. It also results in a crisper diagram with fewer crisscrossing lines.

Additionally, features would ideally be positioned in the middle of the border of the container as shown in the AADL standard. However, that isn't practical at this time from an implementation perspective.

Example

all_features

Contributor

philip-alldredge commented Oct 3, 2017

@reteprelief @lwrage @RyanMcilnay Do you have any thoughts on this? I wanted to bring this up for discussion since this is a significant change and a departure from the graphical examples in the standard.

To summarize, I suggest we make the following suggestions to the feature graphics in the graphical editor:

  • Make them the same size. This prevents the size of the features changing when the type of feature changes. Resizing a feature could result in the movement of adjacent features which could cause the user frustration.
  • Wrap features in boxes. This would be similar to how SysML represented ports. This would avoid confusion regarding the feature to which the connection is connected. It also results in a crisper diagram with fewer crisscrossing lines.

Additionally, features would ideally be positioned in the middle of the border of the container as shown in the AADL standard. However, that isn't practical at this time from an implementation perspective.

Example

all_features

@lwrage

This comment has been minimized.

Show comment
Hide comment
@lwrage

lwrage Oct 3, 2017

Contributor

What's the advantage of having the boxes? They seem to add unnecessary visual clutter.
Where do lines (AADL flows and connections) connect to the boxes?

Contributor

lwrage commented Oct 3, 2017

What's the advantage of having the boxes? They seem to add unnecessary visual clutter.
Where do lines (AADL flows and connections) connect to the boxes?

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 3, 2017

Contributor

What's the advantage of having the boxes? They seem to add unnecessary visual clutter.

It is subjective. The reasoning is that there is that crisscrossing lines causes the diagram to look cluttered. The box provides a blank background so the feature graphics are clean and not overlapping the subcomponent/classifier graphics. Event data ports seem to be the most problematic because the graphic is composed of multiple pieces. The notation is inspired by the graphics used by SysML tools. https://www.nomagic.com/images/noteworthy/165/sysml/ExtractStructure06.PNG

Where do lines (AADL flows and connections) connect to the boxes?

The lines would connect at the edge of the boxes. See the image in #228 (comment).

Contributor

philip-alldredge commented Oct 3, 2017

What's the advantage of having the boxes? They seem to add unnecessary visual clutter.

It is subjective. The reasoning is that there is that crisscrossing lines causes the diagram to look cluttered. The box provides a blank background so the feature graphics are clean and not overlapping the subcomponent/classifier graphics. Event data ports seem to be the most problematic because the graphic is composed of multiple pieces. The notation is inspired by the graphics used by SysML tools. https://www.nomagic.com/images/noteworthy/165/sysml/ExtractStructure06.PNG

Where do lines (AADL flows and connections) connect to the boxes?

The lines would connect at the edge of the boxes. See the image in #228 (comment).

@lwrage

This comment has been minimized.

Show comment
Hide comment
@lwrage

lwrage Oct 4, 2017

Contributor

Well, I don't really like the boxes, but it's a matter of taste. It's also a question of how much the graphical editor should stick to the graphics as used in the standard document.
More importantly, lines connect to specific points on the box (one for connections from the outside, one for connections/flows inside the component), or will it look like all lines go to the center of the box but are covered by the (opaque) box? I'd very much prefer the first option, I find the second one rather ugly. Again, a matter of personal taste.

Contributor

lwrage commented Oct 4, 2017

Well, I don't really like the boxes, but it's a matter of taste. It's also a question of how much the graphical editor should stick to the graphics as used in the standard document.
More importantly, lines connect to specific points on the box (one for connections from the outside, one for connections/flows inside the component), or will it look like all lines go to the center of the box but are covered by the (opaque) box? I'd very much prefer the first option, I find the second one rather ugly. Again, a matter of personal taste.

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 4, 2017

Contributor

Personally, I'm not sure whether I like the boxes or not in any case, I do think the features should be switched to a uniform size to facilitate switching types. It seems the preference would be for the lines to connect to the outside of the features at fixed points. In that case, fixed points on the outside of the box would be used.

@smithdtyler any additional thoughts?

Contributor

philip-alldredge commented Oct 4, 2017

Personally, I'm not sure whether I like the boxes or not in any case, I do think the features should be switched to a uniform size to facilitate switching types. It seems the preference would be for the lines to connect to the outside of the features at fixed points. In that case, fixed points on the outside of the box would be used.

@smithdtyler any additional thoughts?

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 4, 2017

@philip-alldredge Fixed points would help a lot with clarity in connections. I'm not strongly wedded to the idea of boxes, but I like that they eliminate the visual overlap otherwise shown with icons on the borders of components.

I would also be happy with hiding the edge of the component where a port would otherwise obscure it, as mocked up below:

screen shot 2017-10-04 at 10 55 59 am

This could also be accomplished by changing the color of the component boundary where it collides with the bounding box of the icon, perhaps to light gray.

smithdtyler commented Oct 4, 2017

@philip-alldredge Fixed points would help a lot with clarity in connections. I'm not strongly wedded to the idea of boxes, but I like that they eliminate the visual overlap otherwise shown with icons on the borders of components.

I would also be happy with hiding the edge of the component where a port would otherwise obscure it, as mocked up below:

screen shot 2017-10-04 at 10 55 59 am

This could also be accomplished by changing the color of the component boundary where it collides with the bounding box of the icon, perhaps to light gray.

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 4, 2017

Contributor

@smithdtyler
The only known practical way of implementing that with the current code-base would be to draw the boxes without the border. The box could be translucent or fully opaque. However, doing a box with a border can cause visual issues in my opinion because the background could clash with that of the component or the outside component.

I'm including some example below. The port on the left is using the default background color(white). While the port on the bottom has a user assigned background color.

Example with no transparency

example_no_transparency

Example with low transparency

example

Example with more transparency

example_half

Contributor

philip-alldredge commented Oct 4, 2017

@smithdtyler
The only known practical way of implementing that with the current code-base would be to draw the boxes without the border. The box could be translucent or fully opaque. However, doing a box with a border can cause visual issues in my opinion because the background could clash with that of the component or the outside component.

I'm including some example below. The port on the left is using the default background color(white). While the port on the bottom has a user assigned background color.

Example with no transparency

example_no_transparency

Example with low transparency

example

Example with more transparency

example_half

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 4, 2017

@philip-alldredge Can you make the interior of the icon partly or fully opaque and its bounding box transparent?

screen shot 2017-10-04 at 10 55 59 am2

smithdtyler commented Oct 4, 2017

@philip-alldredge Can you make the interior of the icon partly or fully opaque and its bounding box transparent?

screen shot 2017-10-04 at 10 55 59 am2

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 4, 2017

Contributor

@smithdtyler by interior of the icon, do you mean the convex hull of the feature? In that case, that would only really change event, event data ports, and directional abstract ports. In that case making that fully opaque or translucent with a white background may word. The user specified color could be used for the actual filled area.

Contributor

philip-alldredge commented Oct 4, 2017

@smithdtyler by interior of the icon, do you mean the convex hull of the feature? In that case, that would only really change event, event data ports, and directional abstract ports. In that case making that fully opaque or translucent with a white background may word. The user specified color could be used for the actual filled area.

@smithdtyler

This comment has been minimized.

Show comment
Hide comment
@smithdtyler

smithdtyler Oct 4, 2017

@philip-alldredge Yes, I think we're on the same page.

smithdtyler commented Oct 4, 2017

@philip-alldredge Yes, I think we're on the same page.

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 5, 2017

Contributor

Sounds good.

To summarize this and changed being made for #229:

  • Adjusting size of ports to be the same size.
  • Features will have a fixed anchor point for connections.
  • Directional abstract features and event ports will have a background which is shaped like a convex hull. It will be white and be completely opaque. The latter is something that we may adjust later as part of refining the implementation.

The change of the size and the fixed anchor points will result in diagrams which has connections whose bend-points no longer line up. This is intended to be a one time change. Moving forward, the size shouldn't change again.

I plan on finishing and pushing the changes Tuesday. This will give additional time in case someone has any additional thoughts on the matter.

Contributor

philip-alldredge commented Oct 5, 2017

Sounds good.

To summarize this and changed being made for #229:

  • Adjusting size of ports to be the same size.
  • Features will have a fixed anchor point for connections.
  • Directional abstract features and event ports will have a background which is shaped like a convex hull. It will be white and be completely opaque. The latter is something that we may adjust later as part of refining the implementation.

The change of the size and the fixed anchor points will result in diagrams which has connections whose bend-points no longer line up. This is intended to be a one time change. Moving forward, the size shouldn't change again.

I plan on finishing and pushing the changes Tuesday. This will give additional time in case someone has any additional thoughts on the matter.

@philip-alldredge

This comment has been minimized.

Show comment
Hide comment
@philip-alldredge

philip-alldredge Oct 10, 2017

Contributor

Implemented in c4cc595.

Contributor

philip-alldredge commented Oct 10, 2017

Implemented in c4cc595.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.