Add up/down keys to inc/dec val in editor spin slider

[Razoric480]

Adds the ability to increment and decrement an integer while focused in the editor spin slider's line edit, via a gui_input event. Also works with shift to increment and decrement by x10, alt for x0.1, and control/command for x100.

Bugsquad edit: This closes godotengine/godot-proposals#29.

[Calinou]

For consistency with web browsers' DevTools, we could use the same modifiers to increment/decrement values:

• If they press up or down, we want to add or subtract 1
• If they hold shift and press up or down, we want to add or subtract 10
• If they hold alt and press up or down, we want to add or subtract 0.1
• If they hold ctrl and press up or down, we want to add or subtract 100. On Mac, we want to use the cmd key for consistency.

https://kilianvalkhof.com/2020/javascript/supercharging-input-type-number/

[Razoric480]

I can add the extra modifiers, sure!

How does DevTools handle integer values and alt?

Looks like Ctrl/Cmd has priority, shift second, then alt, and alt is ignored on integers.

[Razoric480]

An issue occurs with using devtools style is that in GDScript, you can export a variable with a given step. I.E.

@export_range(0, 100, 0.5)
var my_exported_range = 50.0

So the question occurs: if pressing up does 0.5, if the user holds down CTRL/CMD, SHIFT or ALT and presses up, how does the number react? 50.0, 5.0, 0.5, 0.05?

The default step for floating point numbers is 0.001, furthermore. Unless we force the values to 100, 10, 1, 0.1, that makes even ctrl/cmd have only a small effect.

EDIT: One suggestion is to make modifier-less up and down use step, and the rest go with their devtool style of 100, 10 and 0.1.

[coppolaemilio]

Any chance we can seem some action here again? I still press up and down when selecting items in the inspector and I always remember about this PR 🙈

[Calinou]

Tested on the latest master branch (after rebasing), it works as intended. Looks good from an UX and implementation perspective.

However, with floating-point properties, changing the value using Up/Down without holding any modifiers will change the value by the smallest allowed step (typically 0.001). We should change this so that the step is always 1 when not using a modifier, for consistency with integer properties.

[Razoric480]

The issue with that is that it steps on the toes of the export hint. I.E.:

export(float, 100, 1000, 20) var value: float

will make up and down go by steps of 20 because the inspector has it as its value. If someone sets theirs to 0.25, but we force it to 1, that creates a dissonance.

[Calinou]

will make up and down go by steps of 20 because the inspector has it as its value. If someone sets theirs to 0.25, but we force it to 1, that creates a dissonance.

For the keyboard shortcuts, I was thinking we should use "our" float step of 1 whenever the property's float step is an integer divisor of 1 (1/2 = 0.5, 1/4 = 0.25, 1/8 = 0.125, …). The default float step (0.001) is 1/1000, so it works here 🙂

When a modifier key tries to set a value not allowed by the float step, it tries to round using trunc() + float_step when increasing the property, and trunc() when decreasing the proprerty. (trunc() rounds towards negative infinity, unlike floor() which rounds towards zero.)

If it's not a divisor, we should use the property's float step instead.

[Razoric480]

Finally got back to this. As suggested by Calinou, it will treat <1 values that are integer divisors as 1, though will use the real step for >1 or when the step causes an invalid value (I.E. a step of 0.25 trying to increase by 0.1 would cause no increase otherwise.)

[groud]

LGTM, I did not get perfectly the logic for choosing hte right value, but the implementation looks good otherwise.

[akien-mga]

Thanks!