On 2010-06-23, at 13:59, Max Carlson wrote: > 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.
Ok. If we are splitting out the meaning of fgcolor and tintcolor, then it seems that we shouldn't have a warning saying you can only use one or the other or that one is deprecated in favor of the other. It seems to me that fgcolor is intended to be something completely different (part of the CSS cascade) and that tintcolor is taking over the old role of what fgcolor used to do if the view only contained a resource. > 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... I think I've been saying this all along. That the transform has more dimensions than a tint. That's not saying that I have any great faith that the basecomponent scheme is the 'right way'. It seems entirely plausible to me that it's way of 'tinting' is confused. > 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. I'm not a color theorist. I have to say from what I read on the web, I'm not even sure we are using the word 'tint' correctly. Everywhere I look, it says that 'tint' means to 'add white to'. And we seem to be talking about adding color, not white. > 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? I think you have to remind me why we went down this tintcolor rathole in the first place. Clearly transform is the more general operation, and tintcolor is some subset of that. So is tintcolor just a shorthand? And if so, we can't deprecate transform, because, as you have concluded, you can't do everything you can do with a transform if you only have the tintcolor API. > 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.
