Fgcolor is currently used to cascade text coloring. We added tintcolor
to separate this from the old behavior where tint/fgcolor would be
applied to all children - including resources. I think this is fine.
In trying to deprecate setColorTransform() I discovered basecomponent is
using transform values that are out of bounds when encoded using a
hexadecimal color, e.g. discreet r g b values are > 255 - meaning the
tint should lighten the art resources. This means they don't fit neatly
into a hex color value... Also, basecomponent.setTint() uses the
percentage values for the transform, while tintcolor uses the offsets -
so I'd need to add a new setter/attribute to cover this. I can't use a
hex color because that doesn't cover the possible values...
Right now I'm leaning towards leaving things the way they are, having
basecomponent call the sprite.setColorTransform() directly to bypass
warnings, which is save because the calls are guarded by a capability
that signifies if color transforms are available. Or, I could remove
the deprecation warnings for setColorTransform() and stop pretending
that we can create a tintcolor that represents the color transform.
Either way, I don't want to add more APIs to LzView - Maynard suggested
moving the tinting/colorization routines to a mixin... Any other ideas?
Regards,
Max Carlson
OpenLaszlo.org
On 6/23/10 8:33 AM, P T Withington wrote:
In your latest change you deprecate fgcolor in favor of tintcolor. If that is
really true, shouldn't the fgcolor setter be changed to call the tintcolor
setter? Right now it seems like fgcolor is basically a no-op.
