godotengine
Fix Spinbox display does not round properly when using decimal custom…
Seems to be working for OP's testcases not really sure if this is the intended behavior for
custom_arrow_step . My implementation feels wrong but then again I don't know what would be the correct implementation
Edit : ~~I think I understand a little more about it now~~
~~Maybe we could give some optional parameter to the _set_value_no_signal instead of overriding it in spinbox? …Or maybe that's a bad idea cause the copyright text will add more line than the actual code…~~
Each set_step() will emit changed signal, so doing it to temporarily adjust step is out of question.
The expected behavior is that custom_arrow_step only affects the value when clicking the arrows and displays it properly rounded. Other actions, like manually typing the value, using mouse wheel or dragging the arrows, should use the regular step.
So can we move shared of Range to protected access modifier and add a private _set_step_no_signal to the spin_box ?
Rounded properly meaning if rounded is enabled we round it up to integer or just the multiple of custom_arrow_step?
How do we handle rounded for arrows when there is no custom_arrow_step ?
I mean rounded to the arrow step, so e.g. if arrow step is 0.1 and you click arrows, you should never see e.g. 6.999999999 like in the issue.
So can we move shared of Range to protected access modifier and add a private _set_step_no_signal to the spin_box ?
It would be nice to solve it without modifying step. If it's not possible, you can wrap set_step() in set_block_signals().
So something like this ? I don't think I can do it without using set_step() (skill issue ig)
set_block_signals(true);
set_step(val);
set_block_signals(false);
It's might be intentional but let me ask this. Should dragging the arrow always clamp to to max_value and min_value ? Regardless if allow_greater or less is toggled?
Also maybe a fuction for set_value_from_arrow could be created so we don't need to change the step but we'll need to acess shared to write the new val.
Something like this ~~https://github.com/shahriarlabib000/godot/commit/8df7288bdff013d7e0f7a19c3f2ac958cccefe09~~
Nvm that wouldn't work. value returned by spinbox isn't rounded properly still.
using snapped seems to be working https://github.com/shahriarlabib000/godot/commit/3b2c59249fabde391df3c77552e50b778c6a0e9b
using snapped seems to be working shahriarlabib000@3b2c592
Should I update to that branch?
is there implementation of exp_edit enabled in master? Should there be?
Seems like arrow step applies even if typing the value manually. This is wrong.
It's might be intentional but let me ask this. Should dragging the arrow always clamp to to max_value and min_value ? Regardless if allow_greater or less is toggled?
That's unrelated to this PR, it should be discussed separately.
Should I update to that branch?
I don't like how it partially duplicates set_value(), but if it works better then ok.
Seems like arrow step applies even if typing the value manually. This is wrong.
What were the values for step and custom_arrow_step ?
I don't like how it partially duplicates set_value(), but if it works better then ok.
Maybe we could give set value () an optional custom_step parameter or maybe that's a bad idea
@KoBeWi So if the step is 0, and the value is being typed, it seems that the displayed value's precision is affected. What if we do something like this? https://github.com/shahriarlabib000/godot/compare/spinBox...shahriarlabib000:godot:spinThyBox
void SpinBox::_update_text(bool p_keep_line_edit) {
//String value = String::num(get_value(), Math::range_step_decimals(get_step()));
double value_for_calculating_precision = get_value();
int decimal = 0;
while((int)value_for_calculating_precision != value_for_calculating_precision) {
value_for_calculating_precision *= 10;
++decimal;
if(decimal >= 10) {
break;
}
}
String value = String::num(get_value(), decimal);
