Disconnect overlay on Symbol widget

[georgweiss]

We have (at least) one OPI where the Symbol widget indicates a state using a color coding scheme. When the associated PV disconnects, the color coding will break as the widget paints a semi-transparent "disconnect overlay" on top of the actual symbol.

We'd like to add the possibility to omit the overlay on disconnect in order to maintain the color coding information. The dotted border would be sufficient to indicate disconnection.

Simplest approach would be to add a boolean widget property.

Any reasons to not go ahead?

[kasemir]

The dotted border would be sufficient to indicate disconnection.

That should be the main idea. We generally aim for a consistent alarm indication,
https://github.com/ControlSystemStudio/phoebus/wiki/Display-Builder-Compatibility#alarm-indication .
It's using the border. It can be disabled, but that's it.
In contrast to EDM or BOY we don't support an alarm sensitive foreground color, background color, blinking etc. because these tend to only be supported by some widgets, and while there's always one person who really wants one of those options, there are usually side effects like changing the background color often requires adjusting the foreground color as well and so on.

We do have very few exceptions where the "disconnected" state is represented in the widget itself, in addition to the border.
The MultiStateLED maps PV values 0, 1, 2, ... to colored states. It has a "fallback" state (label and color) that's used when the value is outside of the defined states, and that includes disconnected.

I think you could make the symbol work the same way. So there's no new "disable_disconnected_overlay" option to modify the alarm handling, but instead a "fallback color" that's used for that rectangle overlay when the PV's value doesn't map to the defined states, and that includes disconnected. Then you allow 'transparent' for that fallback color if you want to not show it.

[georgweiss]

I'm fine taking this one step further to allow customization of the fallback color, which I assume should default to the one currently defined for the disconnected state.

[kasemir]

Great, since values outside of the defined states are currently not indicated at all. If you define states 0, 1, 2 and the value is 10, it shows the symbol for the highest defined state 2. Having a "fallback color" just like the MultiStateLED would help, and yes, that can default to the half-transparent purple currently used for disconnected, since it will in fact be used for disconnected as well.

[krisztianloki]

Widgets usually change a bit more than just showing a disconnected border; they stop showing the value. Text updates switch to show the name of the PV, the LED switches to show the disconnected color so in this sense Symbol was an outlier as it kept showing the image corresponding to the last known value. Of course Symbol is special because we cannot just stop showing the image because that would make the OPI unreadable so I implemented this "semi transparent disconnected overlay" (to mimic LED) over the image. Of course it is not perfect as it mixes with the original colors of the image but I think it is still better than just continue showing the image unchanged (i.e. allowing "transparent" as fallback color).
Also, I've just checked how the MultiState LED works; it does not show the fallback color when disconnected; it shows the disconnected color.

[georgweiss]

Ideally we should make a distinction between fallback and disconnected. I would consider a fallback symbol property that - if not set - defaults to the placeholder symbol. This would make it clear that the widget is seeing unexpected values or that is not configured correctly. As for the disconnected state I would argue that there are use cases where one would like to show the last known value, but otherwise indicate the disconnected state through the border. To make this even more flexible/complex one could consider a disconnected symbol that would override the overlay.