Rule for alarm border visibility applied only when alarm state changes

[georgweiss]

Not sure if this is by design or not:

A rule controlling alarm border visibility will not change the visibility when the rule conditions go from visible->invisible or vice versa. Only when the alarm state changes the rule condition applies.

[kasemir]

I'd say it's driven by the original use case.

Alarms are indicated via a border around the widget. Other tools might also support an alarm sensitive foreground color, background color, blinking colors, ... We don't. It's the border, and by default that's enabled, border_alarm_sensitive=true
https://github.com/ControlSystemStudio/phoebus/wiki/Display-Builder-Compatibility#alarm-indication

border_alarm_sensitive is available in the display editor because sometimes it's helpful to disable the alarm indication. This is usually for text entry fields or buttons that write to PVs that miss PINI, so after an IOC reboot they show up INVALID. The system runs fine, those PVs do have a useful default value, but since they have never been processed, they show up INVALID until an operator once enters something. Yes, this should be fixed on the IOC side because the missing/invalid time stamp also means such PVs cannot be archived or plotted over time. Still, many such PVs exist, and an easy workaround is border_alarm_sensitive=false to disable the alarm indication. This also applies to displays auto-converted from EDM where the disabled alarm indication is copied.

The idea for border_alarm_sensitive is thus a design-time usage. In the editor, you might need to set some widgets to not show any alarm. Nobody anticipated that anybody would want to change border_alarm_sensitive at runtime via scripts or rules. And really, why would you?!

[georgweiss]

Thanks @kasemir for your clarification.

As for the "why"... I am assuming my users may identify use cases where it would make sense to hide the alarm border under certain conditions. In any case, supporting immediate visibility change based on the property value I think would not really change the original use case, right?

[kasemir]

Sure, go ahead and add a property listener to border_alarm_sensitive which triggers a redraw. Adds only a tiny bit of memory to the vast number of displays, but will allow you to change it at runtime.
For fun, if you connect a rule that sets border_alarm_sensitive based on sim://flipflop, you do get blinking alarm borders, something that I would strongly discourage but now it'll be possible

[kasemir]

For changing machine modes that should enable/disable alarms, at the EPICS meeting there's a related talk "EPICS Module for Gating EPICS Alarms", https://indico.in2p3.fr/event/37441/timetable