Widgets: Added SliderFloatRange2(), SliderIntRange2() for range selection (#76)

[Entrpi]

Summary

This PR implements range sliders as discussed in #76.

Features:

• Two-handle slider for selecting a min/max range
• Middle bar dragging to move both handles together while maintaining range size
• Hover highlighting to show which handle will be selected on click
• Ctrl+Click text input with "XXX...YYYY" parsing to set both values at once
• Per-handle format strings for different precision on each handle
• Optional step parameter for snapping values

API

bool SliderFloatRange2(const char* label, float* v_current_min, float* v_current_max, 
                       float v_min = 0.0f, float v_max = 1.0f, 
                       const char* format = "%.3f", const char* format_max = NULL, 
                       ImGuiSliderFlags flags = 0, float step = 0.0f);

bool SliderIntRange2(const char* label, int* v_current_min, int* v_current_max, 
                     int v_min = 0, int v_max = 100, 
                     const char* format = "%d", const char* format_max = NULL, 
                     ImGuiSliderFlags flags = 0, int step = 0);

Changes

• imgui.h: Function declarations
• imgui_internal.h: Added SliderRangeActiveHandle context field
• imgui_widgets.cpp: Full implementation
• imgui_demo.cpp: Demo in Widgets/Basic section

Test Plan

• Min handle can be dragged independently
• Max handle can be dragged independently
• Bar between handles drags both together
• Handles cannot cross (min always <= max)
• Hover highlights correct handle
• Multiple SliderRange2 widgets don't interfere
• Ctrl+Click text input works per-handle
• "X...Y" format sets both values

[Entrpi]

[ocornut]

Thanks, wonderful. Further feedback:

• When both handles are at the same location, it feels like the initial click should set an special "unknown" state that's automatically update to left or right handle based on the sign of the accumulator?
• Ideally you can add to imgui_test_suite but I'll add some tests if you can't, it's rather easy for this sorts of things.
• Use single format string? aka "%.3f...%.3f", may require extra parsing work but there are helpers... this makes things more flexible but it's a little more work to customize.
• Displaying the range size.. could use the format string for this purpose? "%.3f...%.3f (%.3f)"... omitting last part would simply hide the value.
• CTRL+Click could default to print "...". Enter should definitively.
• Using .. instead of ... may be faster to type, but when parsing we should decide to accept any number of points.
• Default display format could match the "..." ?

What's your opinion on those?

• Moonshot: if min and max values are contiguous, and we adopt the format string ideas above, we could technically use SliderFloat2() with a ImGuiSliderFlags_Range value valid for 2D and minimize new API. Not sure if it is a good idea but it's technically quite at reach.

[ocornut]

I was having a bad day so the swift and unusually quality updates in this PR are very comforting! Thank you!

[Entrpi]

That means a lot to hear, glad I could brighten your day a bit! Hope things turn around for you.

Addressed the feedback:

API changes:

• Single format string API - removed format_max parameter
• Format string accepts any number of dots as separator (.., ..., ....)
• Format like "%.2f...%.2f (%.2f)" displays range size

Behavior:

• Default display uses " - " separator
• Ctrl+Click text input shows "min...max" format by default
• Accepts both "..." and " - " as input separators
• When handles overlap, drag direction determines which handle moves (undetermined state until drag threshold reached)

Tests: ocornut/imgui_test_engine#88

All 5 tests pass:

• widgets_slider_range2_overlap_resolve
• widgets_slider_range2_text_input
• widgets_slider_range2_text_input_dash
• widgets_slider_range2_no_cross
• widgets_slider_range2_int

Let me know if you'd like any adjustments!

[Entrpi]

Also implemented the moonshot: added ImGuiSliderFlags_Range flag.

Now you can do either:

// Dedicated function
SliderFloatRange2("range", &min, &max, 0.0f, 1.0f);

// Or use SliderFloat2 with flag
float v[2] = { min, max };
SliderFloat2("range", v, 0.0f, 1.0f, "%.3f", ImGuiSliderFlags_Range);

Both approaches work identically. The flag version routes through SliderScalarN when components == 2.

[ocornut]

Thanks, please give me some time to digest all that and get through all details.
There's quite too much code right now (+670 lines) so I will aim to simplify some of it.
The "moonshot" is mostly an API decision to make.

• You currently have a pass at "parsing" the multi-format format string to extract individual formats but losing the whole string. The core idea is that users should be able to pass e.g. "[%d > %d]" if they like and we display the value this way. I'm going to work on this change since it's going to help me review and simplify the code.

• Do you need the step feature?
  It feels like an unrelated feature. See Adding a step size to DragScalar in addition to v_speed #8026, Feature Request: Slider step/speed flag for mouse delta vs value #3441, DragScalar and SliderScalar with inputs_step #1815 not on principle against it but API being cluttered I may make this a separate thing.

[ocornut]

I'll try work on this on wednesday, please avoid further force-pushing to the branch. 🙏

[Entrpi]

Sounds good, look forward to seeing where you take it!

Yes, I agree re: the API choice. Personally I prefer the "feel" of breaking it out into new functions, but not a strong preference.

I wasn't entirely sure about your intended approach with multi-format strings and just thought through the first thing that made some sense to me. I like your idea, so happy if that's the approach!

I do need the step feature, but it doesn't need to be done as I have.