ENH: color the circles based on alarm severity

[ZLLentz]

Seems to work, needs more testing and some looking over probably.

Rather than waiting for upstream alarm support, let's just get out something useful. Can refactor later, this didn't take very long to implement.

begins #86
tracked at https://jira.slac.stanford.edu/browse/LCLSECSD-14

[ZLLentz]

I suspect this needs to be reworked a bit to run on qt's signal/slots system, but I'm not 100% sure. There is some performance degradation on load and I assume it's related to the ophyd thread (which is why I didn't push to merge yet)

[klauer]

I think you're right as to needing signals/slots: setStylesheet itself probably isn't even safe to call from the ophyd dispatcher thread (even if it isn't crashing now).

[ZLLentz]

I'm not seeing the performance issues I saw previously- but yeah, I'm going to rework to avoid issues like you are describing. I haven't had time to really test this overall, I suppose it needs a pamm where I can intentionally cause alarm states and disconnects/reconnects.

To do this properly I might need to set up a bunch of pydm channels per device- and at that point it seems like something to handle in typhos.

[klauer]

Maybe a mock IOC where you can easily set status/severity to play around with it? caproto would be easy, and softIoc not so bad either

[ZLLentz]

Ah, good point, and then if I do it in typhos e.g. making classes like TyphosAlarm (summarizes alarm state, offers some signals) and TyphosAlarmIndicator for display it becomes pretty straightforward to test on a smaller scale. Then it can be brought here for the grid.

[klauer]

I like that plan quite a bit - keeping it nice and reusable as TyphosAlarm*

[klauer]

This will be superseded by an upcoming LUCID PR, using pcdshub/typhos#441
(A reminder to close this when you get back, Zach)

[ZLLentz]

Yes, indeed, closing in favor of #91