Open rcoopr opened 1 month ago
I was initially confused about this as well, but the { alpha: true }
option only applies to how number
values are parsed into colors, not string
values.
(See how options / input params are processed for numbers vs for strings.)
Similarly, the {type: 'float' | 'int'}
option only applies to object
color values.
It's kind of subtle, but this is consistent with how these options are explained and demonstrated in the docs.
I agree it's consistent, but it's very easy to think that the string input with alpha: true was just left out of the docs, because if you included every variation then nobody is going to read the 86 page long docs.
I see that it's not a bug. I think it's not very useful/confusing to have a specific flag to include alpha but not have it work in some scenarios.
Yeah for sure — or some kind of generic typing approach that would restrict the available options based on the type of the bound value might help.
I'm working on a Tweakpane plugin to expand color handling by using the ColorJS library to back the internal color representation. This will bring support for CSS 4 color strings / more modern syntax, along with support for additional object / tuple param types. Hoping that can help with more demanding color use cases. Should be released in a week or two.
Basically, Tweakpane respects a bound value. I assume that parameters with initial values like '#ff0'
might not support alpha.
Users need to specify the alpha option explicitly if the pane cannot determine wheather the parameter has an alpha field. For example, 0xff0055
(in decimal: 16711765
) can be interpreted as either rgb(0xff, 0x00, 0x55)
or rgba(0x00, 0xff, 0x00, 0x55 / 0xff)
.
When adding a binding with an initial value of a hex string with 3 or 6 digits (no alpha portion), the controller does not add an alpha slider.
I would expect declaring
{ alpha: true }
to always add a supporting alpha slider. As a workaround, you can add the alpha portion to the hex string.