> But to simplify/generalize this for other themes, if i had the methods > below for determining color variants, i could define only few, and > then let the skin behavior to choose what color (or its variant) to > use (and cache it), without defining a color for background of > buttons, one for labels, etc as you said before, because this > generates visual noise.
Right now, the skins are coded to choose their default colors from specific indexes within the theme's palette, so changing the number of base colors from 8 to anything else would mess with the skins in the theme. > Great, but a better place for these features wouldn't be in a more > generic Theme base class, so any theme could use this ? Or in a > generic Color management utility class, maybe as static methods (ok, > not so much Object Oriented in this case) ... I disagree. The JDK already has such methods (see java.awt.Color.brighter and java.awt.Color.darker), but they didn't suit the needs of this specific theme (we coded the skins in Terra to graphic design specs built by a graphic designer at VMware). The methods are only 4 lines long, and since they hard code a specific increment or decrement in the brightness value, they are very specific to how *this* theme chooses to brighten or darken colors. Other themes might want to do it differently, or raise or lower saturation values. In any case, coding such methods to fit the specific needs of your theme or decorator is trivial. > And so my previous questions for other optional methods to get the > contrast between two colors, get a color variant for a Colour > Blindness Simulation, and many others ... If we had a whole suite of such color methods, then I could see putting them all in a utility class. Do I hear you volunteering to write such a utility? :) -T
