Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added actual logarithmic sliders #1316

Closed
wants to merge 1 commit into from

Conversation

AndrewBelt
Copy link

@AndrewBelt AndrewBelt commented Sep 6, 2017

The slider behavior previously called "logarithmic" is actually polynomial. This is true logarithmic and can be triggered by passing a power argument of 0.0f in SliderFloat.

I left the previous behavior for backwards compatibility, but in my opinion it should be removed and the float power argument should be changed to bool logarithmic.

Also updated demo for "slider log float".

Solves #642

@ocornut
Copy link
Owner

ocornut commented May 2, 2018

@AndrewBelt Looking at this now, how do you think the equivalent code would work with DragFloat() ?

@ocornut
Copy link
Owner

ocornut commented May 2, 2018

@AndrewBelt Going to clarify my question a little bit.

DragFloat() doesn't work by reading/write "absolute" value but rather by increment.
I am interested in how you would pursue the non-linear interaction in this case, since your PR only address SliderFloat().

It would be beneficial to rework the Slider interaction to:

  • Allow clicking and dragging to tweak a value relative to the clicking point (instead of an absolute value write which is almost always non-precise and destructive at the time of the click)
  • Also keyboard modifiers to slow down or accelerate the tweaking, making it that mouse position won't follow the little drag.

So Slider's internal will likely work more like Drag in the future.

(To support new data types such as double and u64 I need to rework some of the logic. e.g. DragFloat may need some sort of "accumulator". But how/when to flush this accumulator into the target value is tricky because the format-string rounding round-trip would have an effect on the target value from half of the minimum step. Need to store the difference back into the accumulator, etc. Anyway it is solvable and I'll implement that soon. But that'll have to be worked along with support for non-linear edition)

@AndrewBelt
Copy link
Author

I haven't looked at DragFloat in a while, but if it works through relative values, you could simply multiply a factor on each mouse delta rather than adding it.

For linear incrementing, you probably do something like

value += mouseDelta * sensitivity / (maxValue - minValue)

For logarithmic parameters, you'd do

value *= powf(maxValue / minValue, mouseDelta * sensitivity)

@GijsBellaard
Copy link

Sorry to bump this request but implementation of proper logarithmic sliders is a must! The last comment of @AndrewBelt should be enough information to properly implement it. If not I'll do it myself :)

@ocornut
Copy link
Owner

ocornut commented Oct 28, 2018

I haven’t had time to look into this, feel free to expand on this PR but also please read my message carefully, consider the use of keyboard/gamepad navigation inputs and DragFloat.

@ocornut
Copy link
Owner

ocornut commented Jul 22, 2020

@AndrewBelt @gijsbel We went quick down the rabbit hole with this, see:
#3361

(May attempt to split-reformulate #3361 into two steps one taking this approach it (power=0.0f == logarithmic) and then all the other code to change signature.)

ocornut pushed a commit that referenced this pull request Aug 17, 2020
ocornut pushed a commit that referenced this pull request Aug 17, 2020
ocornut added a commit that referenced this pull request Aug 17, 2020
ocornut added a commit that referenced this pull request Aug 17, 2020
…rough if power=1.0f, otherwise assert + safe fallback. Remove 3 redirection functions (#3361, #1823, #1316, #642)
ocornut pushed a commit that referenced this pull request Aug 17, 2020
@ocornut
Copy link
Owner

ocornut commented Aug 17, 2020

This is now fully implemented by #3361, finally closing :)

@ocornut ocornut closed this Aug 17, 2020
ocornut added a commit that referenced this pull request Aug 18, 2020
…, #1823, #1316, #642, #1829, #3209)

Technically API breaking (but ImGuiDragFlags were pushed on master 16 hours ago)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants