ocornut
More eager colour clamping in ColorEdit4
I deeply apologise for the distraught I caused in #4413 and I have to say this library has been a pleasure to work with over the past months!
If ImGuiColorEditFlags_HDR is disabled, force clamp colour input on drag & drop and CTRL+Click. This will fully prevent col[] variables being set to values out of 0.0f...1.0f range while using the ColorEdit4 widget with this flag unset, instead of just on dragging (does this break other code?).
If the flag was set previously and unset later, the values will be clamped upon interacting with the widget (like previously with dragging). Judging from the behaviour of other drags/sliders in the demo window, this is intended that it only changes on interacting with the widget. I'm going with the assumption that if you unset this flag later in the lifetime in your app, you can handle this yourself.
Hello and thanks for the PR. Sorry for my late answer on this. It appears difficult for me to decide what is "right". AlwaysClamp is not the default for regular Drag/Sliders because generally it seems better to allow inputting any value manually, rather than preventing inputs because of boundaries that are sometimes arbitrary and limiting. As such it seems consistent with other widgets to NOT add this by default to ColorEdit4.
The consistent option would be to add a ImGuiColorEditFlags_AlwaysClamp flag leading to this behavior. How about this?
Out of curiosity does your code/app absolutely needs this forced clamping on floating point color? (aka e.g. app would crash otherwise)
This will fully prevent col[] variables being set to values out of 0.0f...1.0f range while using the ColorEdit4 widget with this flag unset, instead of just on dragging (does this break other code?).
Judging from the behaviour of other drags/sliders in the demo window, this is intended that it only changes on interacting with the widget.
Correct.
Out of curiosity does your code/app absolutely needs this forced clamping on floating point color? (aka e.g. app would crash otherwise)
While it's certainly able to be worked around, it's one of those places where I wouldn't expect this behaviour from sliders in this specific widget (if used as a colour picker, I expect values within bounds unless I specifically request otherwise) - and in retrospect would spend some time fruitlessly looking elsewhere for potential bugs in my app's logic.
I'm fine with adding the flag instead, in the end I would expect to be able to more or less control the widget without modifying the library if possible.