-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Multiple range sliders #1355
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
Merged
Merged
Multiple range sliders #1355
Changes from 6 commits
Commits
Show all changes
15 commits
Select commit
Hold shift + click to select a range
33b2bd0
make ax.cleanRange work in nested properties
etpinard 0e931d6
rewrite Plots.autoMargin using for-loops
etpinard cebc31c
fixes https://github.com/plotly/streambed/issues/9088
etpinard 95817e8
add range slider data-update test cases
etpinard e97a80e
add range slider `visible: false` supply-default test
etpinard 0713f23
implement multiple range sliders
etpinard b993ac7
add multi-range-slider mock
etpinard ffccc75
update some range slider baseline (sub-px diffs)
etpinard 122d3d5
factor out is-valid-range logic into setConvert helper
etpinard 0b34b30
multiple range slider visual improvements
etpinard 30eda55
tweak range slider handles for symmetry
alexcjohnson 79512b4
round range slider grabber y values and container transform
alexcjohnson 696519b
new baselines (after range slider improvements)
etpinard 84427d5
Merge pull request #1409 from plotly/rangeslider-crisp-round
etpinard 91838f9
add comment about offsets
etpinard File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,34 @@ | ||
/** | ||
* Copyright 2012-2017, Plotly, Inc. | ||
* All rights reserved. | ||
* | ||
* This source code is licensed under the MIT license found in the | ||
* LICENSE file in the root directory of this source tree. | ||
*/ | ||
|
||
'use strict'; | ||
|
||
var Axes = require('../../plots/cartesian/axes'); | ||
var constants = require('./constants'); | ||
|
||
module.exports = function calcAutorange(gd) { | ||
var axes = Axes.list(gd, 'x', true); | ||
|
||
// Compute new slider range using axis autorange if necessary. | ||
// | ||
// Copy back range to input range slider container to skip | ||
// this step in subsequent draw calls. | ||
|
||
for(var i = 0; i < axes.length; i++) { | ||
var ax = axes[i], | ||
opts = ax[constants.name]; | ||
|
||
// Don't try calling getAutoRange if _min and _max are filled in. | ||
// This happens on updates where the calc step is skipped. | ||
|
||
if(opts && opts.visible && opts.autorange && ax._min.length && ax._max.length) { | ||
opts._input.autorange = true; | ||
opts._input.range = opts.range = Axes.getAutoRange(ax); | ||
} | ||
} | ||
}; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -48,4 +48,6 @@ module.exports = { | |
handleRadius: 1, | ||
handleFill: '#fff', | ||
handleStroke: '#666', | ||
|
||
extraPad: 15 | ||
}; |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I got this right. I would appreciate having something take a second 👁️ at it though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess something in here is responsible for the small position differences in the mocks? I'm not bothered by the differences, except that some of the new ones look a little bit fuzzier than the old ones. Can you try and round it so that the outer edges of the range slider border are exactly on a pixel boundary, even if you have non-integers in
layout.height
, the margins,rangeslider.borderwidth
and anything else that comes into the calculation?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexcjohnson some improvements on:
multiple-rangesliders...rangeslider-crisp-round
I think the mocks look better to my 👀 , would you mind taking a look at them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this isn't new but I'm just noticing it now while we're here: should we switch
handleStroke
to beColor.defaultLineColor = '#444'
instead of#666
as it is now? And to avoid duplication,handleFill = '#fff'
is already available asColor.background
- to explicitly match how we define zoombox cornersThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
5a649f0 gives
is that what you had in mind?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The image you've pasted here is blown up (with browser zoom?), so the rounding isn't quite right and consequently there are still some odd 1-pixel effects at the corners. When I look at the rangeslider-crisp-round branch locally it looks almost perfect.

I realize this is a borderline obsessive ask (which side of the border?) so I did it myself in 29a31d5 and b49ea77. I just tweaked it a tiny bit to get the symmetry right: both handles the slightest bit more on the dark side. I suppose we could bump the width either up or down 1px so it would be possible to have them each exactly symmetric across the dark/light line, but to my eye anyway symmetry between the two handles is more important. Also included rounding of everything that goes into the grabber position before offsetting, because sometimes we were still getting a non-integer starting point, making the half-pixel offset moot. Kind of annoying but I think now it's really truly guaranteed to be an honest rectangle.
Seem reasonable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aaand in case you weren't 100% convinced I'm being obsessive - I've got a retina display on my laptop, and a non-retina external monitor. The retina display still rounds off all the corners, since it doubles the real number of pixels displayed. I'd say this looks fine, perhaps even better than the perfect sharp corners on a non-retina display - because it's a consistent look and the missing pixels are smaller than the line width so the line really looks rounded, not broken like it did on regular monitors before. Screen shot blown up so you can see the individual retina pixels:
