Scaled sliders - convergence with bqplot and altair

The convergence of altair, bqplot and Jupyter interactive widgets

A quick unordered list of issues that seem unrelated at first but will all come together nicely with this proposal

• @jdemeyer, in his work on Sage integration, fixed some semantics on our use of isinstance. He suggested that instead of having separate IntSlider and FloatSlider, we merge in a single numeric slider.

  The implementation of Jupyter widgets for manipulating integers and floats are essentially the same since everything maps to the same front-end implementation, especially since we rely on d3.format mini-language for the readout format. The difference between the integral and continuous variants is merely the default value for the display format.

  Note: in another unrelated discussion, (selection widgets), he taught me to type ABCs) I think that we could try to use a hierarchy of trait types mapping the types ABCs such as [PEP 3141] https://www.python.org/dev/peps/pep-3141/), the type hierarchy for numbers.

• There has been discussions on how we could move away from the current implementation of the Jupyter-widgets slider.

  • We want to get rid of jquery-ui, which is terrible and is not a good citizen of the browser.
  • We want ticks to indicate the current level of the slider, and move the readout so that it does not eat too much of the available length for the slider.
  • @jasongrout was proposing the super-lean no-ui slider as a replacement.

• bqplot users have created helper functions that result in flat figures with brush or index selectors, that they use to select single values or intervals on date scales, logscales, with graduation.

• How current bqplot sccales wrap d3 scales in a meaningful fashion: A d3 scale is typically a mapping between a domain (the data) and a range (the visual quantity that it is being mapped to). A bqplot scale is a jupyter widget that does not have a visual representation. - The model holds the domain information and has no information about the range. - The view is typically instanciated as a child view of another widget (e.g. a figure). So it know the actual dimension of the parent view, and can deduce the range. - The view is the object holding the d3 scale, since it has all the information about domain and range.

Proposal

• We introduce bqplot-like scales as jupyter widget scales (linear, dates, ordinal, color), and maybe refactor the ones of bqplot to use those.
• sliders and progress bars will hold a scale. A linear slider will simply have a linear scale. A selection slider will have an ordinal scale etc.
• d3 will be used to render the widgets, so that we will be able to get rid of the jquery-ui implementation, and have all the benefits from d3 (tick formatting, minor / major tick marks / slider on color scales etc…)
• This will not require a lot of code from d3, since the project went through a split in multiple standalone projects. In fact, we already use d3.format for the readout.
• The scales would also be used by other projects that need mapping to colors / dates. @maartenbreddels is looking into convergence between bqplot, ipyvolume, pythreejs, and factoring out some these abstractions would help.

[vidartf]

I’ve made a very humble beginning for this in https://github.com/vidartf/ipyscales. Any and all input is welcome 👍

[jasongrout]

This is related to #1134.