Stephanie writes:
> And another opinion -
>
> The MEDM way is good though I would add an explanation of what it
> means to an easily accessible "help" display.
>
> If the decision is to go with some sort of color coding, please
> please please let the color be configurable! I was dismayed that
> the color chosen for when a color rule cannot be resolved is white
> and not configurable (on our system, magenta would be a better color
> leaving white to mean channel-cannot-be-connected though it would
> also be nice if the channel-not-connected color is configurable too,
> sigh).
The color model for edd/dm is currently based upon using colors that are in
the "color map" for the display (or the external color palette.) These
colors are specified using RGB values, not the "named color" model. Although
it is quite possible to allow color configurations as args, resources,
etc., I'd prefer not to do so. Would it be sufficient to add a field to
the color rule configuration to allow selection of a color in the case that
color rules could not be resolved(just as one can select default fg and bg)?
In a similar fashion, what about allowing fg and bg color selection for
"not connected" to be available as part of the "modify display attributes"?
Deb
- Navigate by Date:
- Prev:
Re: "dm" and Access Security Jeff Hill
- Next:
Re: EPICS Access Security Andrew Johnson
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: EPICS Access Security Jeff Hill
- Next:
Re: EPICS Access Security Andrew Johnson
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|