-
Notifications
You must be signed in to change notification settings - Fork 3
Keep line endings outside of component boundaries #228
Comments
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? |
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. |
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. |
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. |
This might help, but it would also add more content to the diagram, which could increase visual clutter.
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):
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.
|
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.
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.
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.
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.
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 SystemsExample Processes |
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? |
OK, the box seems like a good solution then.
Works for me. |
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. |
Makes sense, I wouldn't want time spent on code that will soon be discarded.
Feel free to schedule a conference call if that's easier than github. |
@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:
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 |
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
The lines would connect at the edge of the boxes. See the image in #228 (comment). |
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. |
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? |
@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: 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 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 transparencyExample with low transparencyExample with more transparency |
@philip-alldredge Can you make the interior of the icon partly or fully opaque and its bounding box transparent? |
@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. |
@philip-alldredge Yes, I think we're on the same page. |
Sounds good. To summarize this and changed being made for #229:
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. |
Implemented in c4cc595. |
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.
Moving the port to a different side makes it clearer, but the visual collision still looks rough.
The text was updated successfully, but these errors were encountered: