Color and width of connecting lines

[massimo ceraolo]

When drawing connecting lines OMEdit correctly uses as color the lineColor of the connector the line starts from.

When we connect two expandable connectors to each other this implies the connecting lines to be black, which is not optimal. To improve the final result, I propose that when we start a connecting line from an expandable connector we use, as line color, the color of the pixel the drawing line is started from.

I think Dymola uses this technique. I enclose two pictures showing both results.

---

Furthermore, OMEdit uses ticker lines when connecting two expandable connectors. This is useful and nice, since it recalls that that is a channel for signal, possibly carrying many signals simultaneously.

Thick lines are used also when connecting model arrays. When connecting an expandable connector to a scalar model, however, thin lines should be used. Currently OMEdit uses a thick line if the drawing starts from the expandable connector, a thin one if the reverse is true. I understand that when a connecting action is initiated from an expandable connector the line should be initially be drawn as think (OMEdit does not know the connection target). But when the connection is finalised, if the other-side connector is a regular (non array, non-expandable) connector, the final thickness should be converted into thin.

[Adeel Asghar]

When we connect two expandable connectors to each other this implies the connecting lines to be black, which is not optimal. To improve the final result, I propose that when we start a connecting line from an expandable connector we use, as line color, the color of the pixel the drawing line is started from.

That's not true. Even in the case of expandable connectors the line color of the first shape in the icon list is used. Since the ControlBus doesn't have any icon shape that is why we use black.

I think Dymola uses this technique. I enclose two pictures showing both results.

No. Dymola is doing the same as we are doing but if Dymola fails to find a shape it looks for the shape in the inherited classes. We can also do that.

• Note that if you take a look at ControlBus code you will see that it extends from Modelica.Icons.SignalBus and SignalBus has a rectangle with yellow line color as a first shape. You don't see the rectangle in the view but you can see it in the code.

[Adeel Asghar]

Fixed in 390f239/OMEdit.

[massimo ceraolo]

Replying to adeas31:

When we connect two expandable connectors to each other this implies the connecting lines to be black, which is not optimal. To improve the final result, I propose that when we start a connecting line from an expandable connector we use, as line color, the color of the pixel the drawing line is started from.

That's not true.

What is no true? The connect line between expandable connectors is black, we agree on this. Then I just made a proposal, which cannot be neither true nor false.

No. Dymola is doing the same as we are doing but if Dymola fails to find a shape it looks for the shape in the inherited classes. We can also do that.

Nice, whatever Dymola and does, if you are able to obtained the expected result, I'll be very happy.

[Adeel Asghar]

Replying to ceraolo:

Replying to adeas31:

When we connect two expandable connectors to each other this implies the connecting lines to be black, which is not optimal. To improve the final result, I propose that when we start a connecting line from an expandable connector we use, as line color, the color of the pixel the drawing line is started from.

That's not true.

What is no true? The connect line between expandable connectors is black, we agree on this. Then I just made a proposal, which cannot be neither true nor false.

No the connect line between two expandable connectors is not always black. Its the line color of the first shape of the starting connector.

Please try the latest changes I have done.

[massimo ceraolo]

Please try the latest changes I have done.

I suppose that we should choose a way to decide the connection line colour that keeps the expandable connector colour when connecting connectors from the class Modelica.Icons.Signalbus (and from the clas Modelica.Icons.SignalSubBus) to each other.
Maybe your criterion is more rational that the one needed to attain this, but MSL is there and I think we should adhere to the present MSL choices. Do you agree?

If I'm not wrong after your latest changes the connecting line between two instances of connectors Modelica.Icons.Signalbus is still black.

[Adeel Asghar]

I think we both are on the same path. I agree that the expandable connector color should be used. The question is how do you get that color, the expandable connector is shape or a combination of the shape, I use the first shape line color for the connection color.

If I'm not wrong after your latest changes the connecting line between two instances of connectors Modelica.Icons.Signalbus is still black.

No. Its yellow.

[massimo ceraolo]

No. Its yellow.

I've just double-checked under Linux (Ubuntu 18.04) with today's nightly build:

OMEdit 1.13.0~dev-137-g0e9c2ff
Connected to OpenModelica 1.13.0~dev-1195-g6d891ea

I still get black connecting lines, when connecting Modelica.Icons.Signalbus instances.

Do you think there might be differences between OS's?

[massimo ceraolo]

Do you think there might be differences between OS's?

Maybe this is due to #5058

[Adeel Asghar]

Yes.

OMEdit 1.13.0~dev-137-g0e9c2ff is from July. We are working on fixing the Linux and MAC builds.

[Francesco Casella]

The Linux nightly is online again since Aug 21, currrently OpenModelica 1.13.0~dev-1297-g6c67337

[massimo ceraolo]

I checked with Windows.
1) connection between expandable connectors is OK.
2) connection from a block into an expandable connector is OK.
3) connecting from an expandable connector into a block automatically adjusts connection line size: OK.

good work!
As a final adjustment, I would recommend that when a connection is established from an expandable connector into a block, in addition to adjust the size to what required by the block, also the color would be adjusted to the one of the connected block. If we leave things as they are now, the colour of this connection depends on what it is started from, which seems unreasonable.

A final note: in OMEdit, in general clicking on an existing connection selects it and small red squares are displayed as a visual glitch of what is selected. Currently this is not true for connections involving expandable connectors. Is it possible to make red squares to be displayed also in this later case?

Thanks again.

[Adeel Asghar]

Replying to ceraolo:

I checked with Windows.
1) connection between expandable connectors is OK.
2) connection from a block into an expandable connector is OK.
3) connecting from an expandable connector into a block automatically adjusts connection line size: OK.

good work!

Thanks!

As a final adjustment, I would recommend that when a connection is established from an expandable connector into a block, in addition to adjust the size to what required by the block, also the color would be adjusted to the one of the connected block. If we leave things as they are now, the colour of this connection depends on what it is started from, which seems unreasonable.

Why do you recommend this? Why do you think we should use the color of the end connected block?

A final note: in OMEdit, in general clicking on an existing connection selects it and small red squares are displayed as a visual glitch of what is selected. Currently this is not true for connections involving expandable connectors. Is it possible to make red squares to be displayed also in this later case?

Do you have a use case for it? I don't do anything different in the code for expandable connectors in that case. You should see red squares when you select a connection line.

Thanks again.

[massimo ceraolo]

As a final adjustment, I would recommend that when a connection is established from an expandable connector into a block, in addition to adjust the size to what required by the block, also the color would be adjusted to the one of the connected block. If we leave things as they are now, the colour of this connection depends on what it is started from, which seems unreasonable.

Why do you recommend this? Why do you think we should use the color of the end connected block?

as I said, If we leave things as they are now, the colour of this connection depends on what it is started from, which seems unreasonable. I.e. the same connection would be blue if it is started from the block, yellow if from the expandable connector! I think the user will understand yellow connection lines as lines representing a bus; so when we connect a block to an expandable connector, the colour should be equal to the block's.

A final note: in OMEdit, in general clicking on an existing connection selects it and small red squares are displayed as a visual glitch of what is selected. Currently this is not true for connections involving expandable connectors. Is it possible to make red squares to be displayed also in this later case?

Do you have a use case for it?

Consider the enclosed Connections_.mo. I enclose what I see when clicking on any of the connections with OM and Dymola. In OM we have a few issues:

• connection between step2 and integrator2 is not well visible because the red squares are below connectors (should be above)
• connection between signalBus3 and signalBus4 is especially tricky since no red quare is visible.

I think that everything will be solved if red squares are displayed on top of all the other shapes.

[Adeel Asghar]

I have fixed the line color now. So if one of the connector is a block then we use its color instead of expandable connector color. 53e32ce/OMEdit.

The red squares issue can't be fixed now. The reason is explained in the point 3 of ticket:4645#comment:16. I restructuring of how the components, connectors and connections are drawn is required.

[massimo ceraolo]

Replying to adeas31:

I have fixed the line color now. So if one of the connector is a block then we use its color instead of expandable connector color. 53e32ce/OMEdit.

Thank you!

The red squares issue can't be fixed now. The reason is explained in the point 3 of ticket:4645#comment:16. I restructuring of how the components, connectors and connections are drawn is required.

Just out of curiosity: do you have plans to make this restructuring?
From your words I understand that it would cover also the issue discussed in #4645, which would be very nice. In case you plan something, will it correct also the fact that conditional conductors today are visible, and allow connections even they should'n because disabled? E.g. the thermal pin on resistors.

[Adeel Asghar]

Replying to ceraolo:

Replying to adeas31:

I have fixed the line color now. So if one of the connector is a block then we use its color instead of expandable connector color. 53e32ce/OMEdit.

Thank you!

The red squares issue can't be fixed now. The reason is explained in the point 3 of ticket:4645#comment:16. I restructuring of how the components, connectors and connections are drawn is required.

Just out of curiosity: do you have plans to make this restructuring?
From your words I understand that it would cover also the issue discussed in #4645, which would be very nice. In case you plan something, will it correct also the fact that conditional conductors today are visible, and allow connections even they should'n because disabled? E.g. the thermal pin on resistors.

Yeah I have plans to fix that and yes it will also fix #4645 but I can't guarantee a time for it.
The conditional connectors are not related to it. Its a whole different story.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed