Lack of standard for deriving connect-Line style from connector icon

[henrikt-ma]

I think that the practice of deriving the styling for a new connect Line-annotation based on connector graphics is more or less a de facto standard. It should be made a proper standard.

(Once there is a standard, the Modelica.UsersGuide.Conventions.Icons should also be updated, but that's an issue for the ModelicaStandardLibrary project.)

[henrikt-ma]

As a starting point for the discussion, my understanding that all style attributes should be taken from the first graphical primitive of the connector class' Icon-annotation. Further, these are the attributes that would be transferred to the connect Line-annotation:

• lineColor (mapped to color of the Line)
• pattern (why on earth does FilledShape call it just pattern and not linePattern?)
• lineThickness (mapped to thickness of the Line)
• smooth

In particular, none of the properties from GraphicItem are transferred (allowing the primitive to have visible = false if it would disturb the look of the icon). Further, a Line would not be usable, as it has the attributes color and thickness rather than lineColor and lineThickness.

Wouldn't it make a lot of sense to be able to use a Line instead of a filled shape?

[henrikt-ma]

I suppose that all compatible connectors are expected to have consistent attributes affecting connection styling, so that it doesn't matter whether attributes are taken from a or b in connect(a, b). Maybe this should be mentioned as a non-normative recommendation in the specification, in addition to clearly recommending it in Modelica.UsersGuide.Conventions.Icons?

[maltelenz]

I suppose that all compatible connectors are expected to have consistent attributes affecting connection styling, so that it doesn't matter whether attributes are taken from a or b in connect(a, b). Maybe this should be mentioned as a non-normative recommendation in the specification, in addition to clearly recommending it in Modelica.UsersGuide.Conventions.Icons?

I don't think this is the case when using expandable connectors for buses, see for example Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.Utilities.AxisType2, where the two ends of connections to the sensors differ.

[henrikt-ma]

Right. Could it be as simple as saying that the connection line style should never be inferred from the icon of an expandable connector, so that one doesn't need to worry about styling of the first graphical primitive of an expandable connector icon?

[maltelenz]

Or that the styling is inferred from the starting/first side of the connection. This allows the user to choose the styling by starting the connection at the corresponding end.

[HansOlsson]

Right. Could it be as simple as saying that the connection line style should never be inferred from the icon of an expandable connector, so that one doesn't need to worry about styling of the first graphical primitive of an expandable connector icon?

That doesn't work when connecting between two expandable connectors, as is also seen in Modelica.Mechanics.MultiBody.Examples.Systems.RobotR3.Utilities.AxisType2 (the two yellow lines).

An alternative would be to prefer another connector, or care whether it is a sub-part or not.

Or that the styling is inferred from the starting/first side of the connection. This allows the user to choose the styling by starting the connection at the corresponding end.

Could possibly do, but I'm not sure if we need to have those details specified.

[henrikt-ma]

Or that the styling is inferred from the starting/first side of the connection. This allows the user to choose the styling by starting the connection at the corresponding end.

Could possibly do, but I'm not sure if we need to have those details specified.

Right. It would have been different if the connect-equation didn't have its own Line styling, so that the line would dynamically change style when the connector icon changes. What is needed now is just a convention that gives library developers a tool-independent way of suggesting the Line style for new connections. Perhaps the non-normative recommendation should simply be to make an active choice of Line style hint for every connector icon?

[DagBruck]

After looking at the Dymola code, let me add a few points to Henrik's description.

• Dymola also sets line color, line pattern and thickness attributes. The others are reset to defaults, including smooth.
• We copy the attributes from the first enabled rectangle or polygon primitive, no others. Not from circles, for example. I'm sure there was a discussion behind that decision, but I have now forgotten the motivation.
• For some obvious cases we do not copy an attribute: line pattern "none" and line thickness <= 0. This means that you can in fact set the color of the connection to a different color from the connector, by using one color as fill color and and different color for line color (with pattern "none").

[henrikt-ma]

• We copy the attributes from the first enabled rectangle or polygon primitive, no others. Not from circles, for example. I'm sure there was a discussion behind that decision, but I have now forgotten the motivation.

By enabled, do you mean the absence of visible = false? (Would sound like an unnecessary restriction to me, especially in view of allowing the trick to set LinePattern.None and FillPattern.None – do you remember any motivation behind this restriction?)

[DagBruck]

• We copy the attributes from the first enabled rectangle or polygon primitive, no others. Not from circles, for example. I'm sure there was a discussion behind that decision, but I have now forgotten the motivation.

By enabled, do you mean the absence of visible = false? (Would sound like an unnecessary restriction to me, especially in view of allowing the trick to set LinePattern.None and FillPattern.None – do you remember any motivation behind this restriction?)

Yes, that's what I mean by enabled (or rather what the comment in the code said). No, I don't remember the motivation anymore. Maybe that visible=false should mean not only out-of-sight but also out-of-mind? It may be an unnecessary restriction, but it's what Dymola does today.

[henrikt-ma]

Yes, that's what I mean by enabled (or rather what the comment in the code said). No, I don't remember the motivation anymore. Maybe that visible=false should mean not only out-of-sight but also out-of-mind? It may be an unnecessary restriction, but it's what Dymola does today.

I'd find it useful to drop that restriction, as it would provide a better alternative to hiding a small polygon behind other graphics in case the style isn't appropriate for the graphics item at the bottom of the stack. That way, tools could have dedicated support for indicating the presence of this polygon when editing the connector icon, making it easy to see where the styling comes from (as well as changing it) without having any effect when using the connector. Tools could also offer special ways of setting up this invisible polygon at the bottom of the stack, with an extent that is not (or at least extremely unlikely to be) occluded.

Regarding smooth, this is something we (System Modeler) would very much like to be considered part of the styling.