Limit click-dragging behavior on inspector properties and SpinBox to be constrained to the suggested range of that property

[lander-vr]

Describe the project you are working on

PRs, various projects, and an extension.

Describe the problem or limitation you are having in your project

Exposed value properties using or_greater or or_less have poor user feedback and UX in regards to what range is expected, and when an expected range is exceeded.

Properties currently are exposed with an expected or a recommended range (min,max) set as a property_hint flag, but a developer may want to allow a user to go beyond this recommended range because there may be use cases where this is necessary, this allows a lot of flexibility to users.

The issue arises when a user now tries to drag-adjust any property using or_greater or or_less in the inspector panel: It very easily goes outside of the expected range, and there is no user feedback that indicates to the user that the value they have just adjusted the property to may be unexpected or not recommended. Floats have some user feedback, since they have a slider that is adjusted to the range, however if the user misses that slider button by a few pixels, they are now clicking the property box and suddenly the sliding behavior is not constrained anymore.

Here is a more concrete/direct example on an INT property for a PR I'm working on.

Currently PROPERTY_HINT_RANGE, "1,20,or_greater" behaves like this:

I'm expecting these values to usually be within a range of 1 to 20. However, I can also imagine situations where a user might want these values to be larger. Even though it is not recommended to do unless you know what you're doing, functionality for it is supported, so arbitrarily limiting this value blind to potential use cases users may run into would be introducing a limitation into the engine that's not strictly necessary. Its current behavior does not communicate which values are normal and expected, and which aren't.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

I recommend we take a look at how Blender handles these cases. It's a tried and tested approach which I'm a big fan of, so I'll propose the same behavior for Godot:

I propose that exposed properties using a limited range inherently have "slider-like" behavior, where adjusting the property through click-dragging keeps it within the predefined range. If a user wants to go beyond this range and or_greater or or_less is allowed, they would have to manually type in a value exceeding this range.

Here are some gifs of its behavior in Blender, as a point of reference:

• A hard limit (you cannot exceed the set value range)
• A soft limit (you can exceed the set value range)

Manually entering values forces a very conscious action, instead of the current behavior where it is something that can easily happen on accident or without the user even being aware of it.

The advantage to this approach is that we can cater to new/inexperienced users and advanced users simultaneously with no tradeoffs.

This provides users with very clear feedback regarding which values are expected. If the user does want to exceed these values, forcing them to manually enter a value clearly communicates to them: "Hey, this is supported, but not necessarily recommended. Make sure you know what you're doing, and if you get weird results that's probably on you.".

I propose this also replaces the current combined slider and property-drag behavior of exposed floats. It is very easy to miss the slider button, and this proposal negates the need for a separate slider on these properties. This has the bonus of cleaning up the UI a bit.

One thing I think that could be worth exploring too is a combined functionality, where there is an expected range that can be exceeded, but there is still a need for a hard-limit to a certain value. e.g. for use cases where the feature breaks beyond a certain value range. But maybe this is too rare in order for this to be worth it, and those value limits could just be introduced in code.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

PROPERTY_HINT_RANGE, "0,100" exposes a slider from 0 to 100 with a hard limit, the user cannot go beyond this range. PROPERTY_HINT_RANGE, "0,100,or_greater" exposes a slider from 0 to 100 with a "soft" limit, the user can go beyond this range if they manually input a value exceeding 100.

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, this is core and introduces UX improvements to any exposed float/int property.

Is there a reason why this should be core and not an add-on in the asset library?

This proposal benefits everyone. It vastly improves engine UX making it more accommodating to new users without introducing any tradeoffs for advanced users.

[passivestar]

this proposal negates the need for a separate slider

I like the idea of not drawing sliders on top of sliders. I like blender's design where they look like progressbars much more

But I'm not super convinced that Blender's way of doing soft limits is the best possible way. The blue bar already communicates the suggested range and requiring users to type in a value to go beyond is a bit too much sometimes. What if it also allowed you to go beyond limits if the current value is already the outer one and you start moving your mouse/finger in the direction of the limit?

Also related to this proposal: some of the sliders (I think the ones that are in [0;1] range) are way too sensitive. For example when trying to drag "Sky Contribution" in WorldEnvironment it feels like it's bugged

[lander-vr]

I like blender's design where they look like progressbars much more

I agree!

What if it also allowed you to go beyond limits if the current value is already the outer one and you start moving your mouse/finger in the direction of the limit?

This could be a good middle ground. It'd make it a bit easier and faster to exceed that range, but it wouldn't give feedback when a value is already at an extremity before the user has even touched it.

What about a modifier key instead? For example holding alt while dragging a property would allow you to exceed the range. This makes it really fast and easy to do but still a deliberate action in any situation, regardless of whether it's at an extremity or not. New users wouldn't easily exceed ranges on accident, and experienced users could still work fast and efficient.

Also related to this proposal: some of the sliders (I think the ones that are in [0;1] range) are way too sensitive.

I think this is an issue where slider sensitivity is predetermined and not taking in account the range of the property (Not sure if this is the case, but it behaves like this at least): For large float ranges you have to drag your mouse an excessive amount to go from 0 to 100%, and for small ranges you lose any fine control. On integer properties you can easily go from 0 into the tens of thousands, which on a range that is restricted from 0-20 like the example I brought up makes click-dragging practically unusable. It also doesn't give any feedback as to what kind of values are expected. An example is the max_polyphony property on the AudioStreamPlayers: I doubt this value is meant to be set to 43000, but you can reach it with ease.

[passivestar]

What about a modifier key instead?

A little less mobile friendly but since it's sort of an advanced feature I think a modifier key for this is fine

[Calinou]

I think it's fine to require (physical or virtual) keyboard input to start going outside the range. We can provide a modifier like Alt for this if we really want to, but I don't expect this to be used very often.