Plotting order

[HansOlsson]

The discussion in #3473 (comment) made me re-run EngineV6 in MSL and plotting the relevant variables - and I then noticed a minor issue:

How does the figure annotation deal with "plotting order"?

Specifically the plot will only be easy to understand if you plot filteredEngineTorque on top of/later than engineTorque; and I couldn't find the order specified - in contrast to the graphical primitives where an order is specified in section 18.6 .

(I know that there's no figure annotation yet for that example, but planning ahead.)

[henrikt-ma]

Do you mean that we should explicitly say that the Figure.plots is an array where the order matters? To me, this goes without saying, similar to that the Plot.curves is an array where the order matters.

However, a related feature we don't have is to define the order of figure groups. For comparison, we have some sort of rule for the dialog tabs and groups, but I must say it's a pretty bad rule we have (to reorder tabs and groups, one needs to alter the declaration order, which could degrade source code readability, lead to unexpected and hard to understand commit diffs, and in the worst case affecting heuristics of model translation). I can clearly see how a group of figures mainly for showing variables used in correctness testing, called Regression Testing should be at the end of the group list.

It would be possible to say that groups are ordered according to order of first appearance, and it would probably not be as bad as the current design for dialog tabs and groups, as reordering Documentation.figures would never affect model translation heuristics. However, first-encounter principle would only work for models without inherited figures; even if we don't care about the order among the base class figures, it would be annoying that the figures groups used or added in the present model cannot be positioned in relation to the inherited groups.

[HansOlsson]

Do you mean that we should explicitly say that the Figure.plots is an array where the order matters? To me, this goes without saying, similar to that the Plot.curves is an array where the order matters.

Yes, and specifically in what orders they are drawn - or something similar.

However, a related feature we don't have is to define the order of figure groups. For comparison, we have some sort of rule for the dialog tabs and groups, but I must say it's a pretty bad rule we have (to reorder tabs and groups, one needs to alter the declaration order, which could degrade source code readability, lead to unexpected and hard to understand commit diffs, and in the worst case affecting heuristics of model translation). I can clearly see how a group of figures mainly for showing variables used in correctness testing, called Regression Testing should be at the end of the group list.

It would be possible to say that groups are ordered according to order of first appearance, and it would probably not be as bad as the current design for dialog tabs and groups, as reordering Documentation.figures would never affect model translation heuristics. However, first-encounter principle would only work for models without inherited figures; even if we don't care about the order among the base class figures, it would be annoying that the figures groups used or added in the present model cannot be positioned in relation to the inherited groups.

The obvious solution would be to define an explicit ordering member, but that also has disadvantages.

[henrikt-ma]

Yes, and specifically in what orders they are drawn - or something similar.

What about legend order? Should it also be specified, or can we leave that for the tools to decide, so that drawing order is the only thing determined by the specification?

[HansOlsson]

Yes, and specifically in what orders they are drawn - or something similar.

What about legend order? Should it also be specified, or can we leave that for the tools to decide, so that drawing order is the only thing determined by the specification?

Leave it to the tools I say; as there are also a number of different placements of the legend.

[HansOlsson]

Modelica Phone Meeting:
Alternative is to have z-depth; discussion about graphical contents of diagram - separate control of legend and plot order can be useful (where legend order is independent of z-depth).
Proposal:
Order based on Z-order (high value close to viewer), and in case of tie use order of appearance. Legend order based on declaration order.

-> @henrikt-ma