Numeric range slider

[gaitat]

It would be nice to have support for a range slider that has two handles to select a range between a min and a max value.

[cocopon]

What are expected input values for that control?

[gaitat]

If I understand correctly, it would be the min value, the max value, the value where the first handle will appear and the value where the second handle will appear. The handles could default to the given min and max values if there are no values given for them.

[cocopon]

For example, X-Y panel will be provided for input {x: 123, y: 456}. So what kind of input values should require a range slider? {min: 0, max: 100}? Are there any other input values for that control?

[gaitat]

It would be the same input that a regular slider has. It would just have two handles instead of one.

[cocopon]

Tweakpane should provide output in the same format as input value because this is tweaking.

const params = {
  range: {min: 0, max: 100},
};

const pane = new Tweakpane();
pane.addInput(params, 'range');

So probably it doesn't have the same input as a regular slider.

[gaitat]

From what I can see at: https://www.jqueryscript.net/demo/Flexible-Touch-Friendly-jQuery-Range-Slider-Plugin-Ion-RangeSlider/ https://www.cssscript.com/demo/animated-customizable-range-slider-pure-javascript-rslider-js/ https://www.jqueryscript.net/demo/Highly-Customizable-Range-Slider-Plugin-For-Bootstrap-Bootstrap-Slider/ https://mdbootstrap.com/plugins/jquery/multi-range/

there are two ways to approach this: One is that each handle tweaks from min to max. The other is that the left handle tweaks from min to value of the right handle and the right handle tweaks from the value of the left handle to the max value.

Personally the second option makes more sense to me. Where the single handle slider returns a value the double handle value returns an object (or something else) with two values.

[cocopon]

I'm not sure that it should be included in the core or be implemented with the plugin system #78...

[marquizzo]

I was just thinking something like this would be very useful. For example, I have 2 values: alpha-low and alpha-high, which takes up 2 sliders and runs the risk of crossing values low > high. I could write checks to prevent this, of course, but it would be super helpful to combine 2 sliders into a single range slider. Something like this

const params = {
    alpha: {low: -0.5, high: 0.5}
}

const pane = new Tweakpane();
pane.addRange(PARAMS, 'alpha');

// Or alternatively, declare the upper and lower bounds of the range:
pane.addRange(PARAMS, 'alpha', {min: -1, max: 1});

Now this way, the Tweakpane automatically drags the low value down if high tries to go below it, and vice-versa.

[cocopon]

Thank you for details. I already know the usefulness of that component, but my concern is... is this common data structure enough to add to the core library?

For example, many famous libraries have Point2D-like class (PixiJS, three.js, ...) so I decided to add its support to the core. But I have barely seen the range-like class or the structure in these libraries.

If it is not common enough, I think that it should be implemented with the plugin system (#78, but not implemented yet).

[marquizzo]

Oh, I see what you mean. Yeah, Three.js doesn't exactly have a one-dimensional range data structure. The closest is a Box3 Bounding Box, but that's three-dimensional.

Nonetheless, I think this would be very useful, as many of its math utilities require a low and high one-dimensional value.

[gaitat]

@cocopon I actually think that this component is much more useful (to me at least) than the Point2D component. But this aside, providing the functionality is much more important (to me) that where the functionality lives. Once it is implemented in the core ... you can decide if it belongs there or in a plugin (and hopefully it will be easy to move).

[cocopon]

@gaitat

this component is much more useful than the Point2D component

It's your personal opinion... If I accepted all suggested components, this library would become huge, less maintainable, and hard to understand the usage.

I think that one of the important things for a feature request is a reason that is OBJECTIVELY convincing. (e.g. famous library has a support for this kind of data structure)

Once it is implemented in the core ... you can decide if it belongs there or in a plugin

I disagree. This is a broken change and force users to fix their code. As a package maintainer, I have to be careful about backward compatibilities.

[cocopon]

Tweakpane is now 2.0.0! It has a plugin system so you can register a custom binding view to the pane. https://cocopon.github.io/tweakpane/plugin.html

FYI: Here is my first plugin currently working on...

https://user-images.githubusercontent.com/602961/109491994-a3355d80-7acd-11eb-81ce-3cf76ccd15a4.mp4

https://twitter.com/cocopon/status/1366350034531323904?s=20

[cocopon]

Here is the very first version of the plugin: https://github.com/cocopon/tweakpane-plugin-interval

Demo: https://codesandbox.io/s/tweakpane-plugin-interval-6buv9