Not recommended colors in figure in section 17.2 "State Machine Graphics"

[henrikt-ma]

Of the two recommended colors for state machine graphics, I can only find {95, 95, 95} in the figure, used for the state border and transition lines. It's not entirely clear, but the transition text looks black, just like the state component names.

To me, the use of {95, 95, 95} for the transition lines in the figure looks better than the recommended {175, 175, 175}, so maybe someone changed their mind, but forgot to update the recommendation in the text?

Did the same happen to the transition text, that the figure shows the intention of having the text black, but the recommendation in the text is not up to date?

By the way, is it really the business of the specification to recommend colors at all like this, in particular for the states? I mean, I can see how a tool could apply the recommendation when adding a transition, but is a tool really supposed to keep track of what kind of icon is being drawn, and set default color for new graphical primitives depending on whether it is supposed to be used as state machine state or not?

[HansOlsson]

As far as I can see in Dymola:

• The text on transitions are black (cannot see how to change)
• The transition lines as default use {175,175,175}
• The initial state as default use {175,175,175}
  • The states borders use {95, 95, 95}
• Graphics in states don't have any special default
• The name of the states as default use black

So it seems we changed the transition text to black, but apart from that followed what was written. I assume that's to make it more readable.

I can understand that you want to use a consistent color for transitions (including initialState), and not just use the color you used for something else. Note: It's not that you have to keep track of whether it's a state to set a different color - it's that you have to keep track of whether it is a state to draw the state-border in a specific color.

@DagBruck do you have any information?

[henrikt-ma]

Note: It's not that you have to keep track of whether it's a state to set a different color - it's that you have to keep track of whether it is a state to draw the state-border in a specific color.

So that border isn't part of the state's icon? Where is it said that a border should be added? Can the user predict the shape of the border in order to know where to place transition lines in a portable way?

[HansOlsson]

Note: It's not that you have to keep track of whether it's a state to set a different color - it's that you have to keep track of whether it is a state to draw the state-border in a specific color.

So that border isn't part of the state's icon? Where is it said that a border should be added? Can the user predict the shape of the border in order to know where to place transition lines in a portable way?

Good questions, that section is lacking a lot.

Some points based on the specification:

• The "border" is implicit in that it is shown consistently for the states, and there is nothing indicating how it is constructed.
• It would be difficult to create such a border in Modelica as the corners are rounded in a way that cannot be done inside the components.
• Additionally hierarchical state machines (17.3.7) indicate that it is the diagram - not the icon that is shown; because otherwise we wouldn't see stateA in state1.
• The hierarchical state machines also indicate that there is some way of showing the "text-layer" of the model in the diagram; because otherwise stateA etc wouldn't make sense (and no-one would copy it exactly like that).

In Dymola:

• The border is a bit outside the extent of the component; so that even the innermost part of the rounded corner is outside the original component (with some margin).
• It's actually not just a border, but a filled rectangle with rounded corners that has a border. (The fill color is normally white, but when animating state-machines a different color is used for the active one.)
• There is also a line below the name of the state going through the entire rectangle, but the underlying logic is a bit odd. (It looks nicer, but it isn't present in the spec.)
• The transition line is automatically moved to the border; which mean that it will work even with another border - but if you two different tools that will cause the annotations to change back and forth.
• Showing the "text-layer" of the model is possible through some annotations.

So, in order to better standarize this:

• Specify that state machines should have this filled rounded corner background.
• Specify that diagrams are shown for state-machines, or have an general annotation "showDiagram=true" in classes to specify this.
• Specify special text-"macros" that will show the text-layer, e.g. "%stateText".
• More? @DagBruck

I believe we need a PR - or possible even an MCP for this.

[henrikt-ma]

I realize that this is just a minor detail in all of this, but what's the problem here:

• It would be difficult to create such a border in Modelica as the corners are rounded in a way that cannot be done inside the components.

Is it that approximating circular arcs at the corners doesn't come natural with the kind of Bezier splines we have? I'd say what one gets with just the simplest approach of one curved segment per corner would be good enough — definitely not circular, but definitely rounded.

[henrikt-ma]

I believe we need a PR - or possible even an MCP for this.

Sounds like MCP to me. There are enough details here to motivate making a collection of examples with the expected results, and have more than one test implementation before accepting.

In the mean time, I still think the figure of the hierarchical state machine in the specification has a value on the conceptual level; it clearly shows how the state machine works in a schematic way, as a complement to the purely textual description in the listing (where there are no graphical annotations).

[DagBruck]

As far as I can see in Dymola:

• The text on transitions are black (cannot see how to change)
• The transition lines as default use {175,175,175}
• The initial state as default use {175,175,175}
• The states borders use {95, 95, 95}

We have to think twice here, due to the soon-to-be-introduced dark mode in Dymola. (Yes, it's unbearably cute.) The transition lines don't look good with {175, 175, 175}.

Otherwise I don't have much to add to the list.

[HansOlsson]

I realize that this is just a minor detail in all of this, but what's the problem here:

• It would be difficult to create such a border in Modelica as the corners are rounded in a way that cannot be done inside the components.

Is it that approximating circular arcs at the corners doesn't come natural with the kind of Bezier splines we have?

No, it's that circular arcs inside the graphics of the component turn into elliptical arcs when you stretch the component (as is common for state machines).

[henrikt-ma]

No, it's that circular arcs inside the graphics of the component turn into elliptical arcs when you stretch the component (as is common for state machines).

I see. That means we probably don't even want a new graphical primitive for this, as it's weird to introduce a graphical primitive that don't scale in the natural way.

[henrikt-ma]

We have to think twice here, due to the soon-to-be-introduced dark mode in Dymola. (Yes, it's unbearably cute.) The transition lines don't look good with {175, 175, 175}.

Sounds like it would have been better to leave the default color of transition lines for tools to decide, rather than recommending a color that goes hard-coded into the annotations.

[HansOlsson]

Currently the colors are recommended in non-normative text. Proposal: Remove the text about colors, but keep the same colors in the example below.

[HansOlsson]

Agreement.