godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.13k stars 85 forks source link

Always display exported float variables with one decimal, even when whole numbers #1693

Open Arnklit opened 3 years ago

Arnklit commented 3 years ago

Describe the project you are working on: A fur plugin for Godot

Describe the problem or limitation you are having in your project: I'm having issues with not being able to show exported int variables as sliders. See https://github.com/godotengine/godot/issues/42809.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: Part of the reason for not displaying sliders on ints, according to the bug mentioned above, is to easily distinguish them from floats. So it would seem a good improvement to make it easier to distinguish floats by always having them display a decimal.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: image

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

Is there a reason why this should be core and not an add-on in the asset library?: This would have to be changed in core as far as I understand.

aterlamia commented 3 years ago

I was already doing some research for the linked issue and also asked on irc and got this as answer

"aaronfranke[m] Always showing a decimal for floats is a neat idea but it needs to be discussed and applied consistently around the engine. Currently floats that are whole numbers don't show .0"

If it needs to be implemented everywhere it is displayes it might be as easy as removing the "//destroy trailing zeroes" part from

String String::num(double p_num, int p_decimals) in ustring.cpp. If the functionality is still needed for other places or this change will only need to be for the sliders a new function or a toggle (something like String String::num(double p_num, int p_decimals, bool p_keep_trailing_zero)) needs to be added.

And then the code

String EditorSpinSlider::get_text_value() const {
    return String::num(get_value(), Math::range_step_decimals(get_step()));
}

in editor_spin_slider.cpp should be changes to use that new function.toggle

(sorry readded this commit as i added it from a wrong account)

Bhu1-V commented 3 years ago

Hello, So any core members are interested In this feature. Personally, I like the idea.

Calinou commented 3 years ago

@Bhuvan-Vemula Sure, feel free to open a pull request for this :slightly_smiling_face:

Calinou commented 3 years ago

@Bhuvan-Vemula Any progress on this? If you don't plan on implementing this feature, please comment so that someone else can do the work.

akien-mga commented 3 years ago

For the reference, I'm in favor of this change, and other core devs mentioned support too in an informal discussion today (@vnen, @groud, @Calinou). It should be done both for the editor (Inspector, Debugger) and for printing/serialization. I.e. any situation where a float is whole, it should be represented with .0 suffix to be properly distinguished from its integer counterpart.

Over the years this has been a constant source of confusion for new users who do not fully understand what data types they are using behind the scenes with e.g. var a = 5, var b : int = 5 or var c : float = 5. Or worse, with vector types like Vector3(1, 2, 3), which users often wrongly expect to be storing integers (which is now possible in Godot 4.0 using Vector3i).

On the other hand code like var c : float = 5 should still be valid as is, even if print(c) should display 5.0. Only the representation should be changed, not the language itself.

The change should be done for the master branch in priority, and can break compatibility.

We can eventually consider if a backward-compatible change could be added to 3.2 (but then maybe only for the editor display, not for serialization, as this would be a compat breaking change).

akien-mga commented 3 years ago

@Bhuvan-Vemula Any progress on this? If you don't plan on implementing this feature, please comment so that someone else can do the work.

I don't think their comment implied interest in doing the implementation work, only checking if there is support from the developers. So this task can be taken by anyone interested.

1shevelov commented 3 years ago

I want to support @akien-mga's arguments with an one more example which I stumbled upon recently:

var arr: Array = []
for i in 3:
    arr.append(float(i))
print(arr)
print(arr.find(1))

And the output is:

[0, 1, 2]
-1

And this could be very confusing for newbie programmer since the output doesn't give a hint on what the problem is (why find(1) returns "not found" while print() shows that there is a "1" in the array). Another good comment on the topic here.

lyuma commented 2 years ago

I disagree with this proposal. This will make the inspector—already packed with information to read in all cases—more difficult to read, especially if we throw in units as well.

Most values in the inspector are already floating point. Other programs, such as Unity, you type ".0". If you need to lookup the type of a value, we should make it easier to open the Help for the value you're hovering and show the type.

Related to godotengine/godot#61956 : If I type "1/2" in the inspector, it should give me 0.5 not 0

See here for how inspectors typically work in an app like Blender: Screnshot of Blender showing location 1/2, 0.5m, 0m See how integer values like "0" show simply as "0 m". I can type in "0.5" or "1/2" and both are represented as "0.5 m" with decimal place, because they need it.

Zireael07 commented 2 years ago

As a compromise, what about showing 1.0 as "1."?

This way it's clear it's a float (which is the point of the proposal) and saves one character for those on narrow screens/with narrow inspector

YuriSizov commented 2 years ago

We've discussed it during the proposal review meeting, and were in general agreement that this is a useful feature to have.

aaronfranke commented 12 months ago

Related proposals and PRs: