Fix hover label positioning for bar trace with set `width` by etpinard · Pull Request #1527 · plotly/plotly.js

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard · 2017-03-29T19:55:27Z

fixes#1317 - at least the hovermode: 'closest' part, see #1317 (comment) for more details.

TODO:

add more tests!

- so that traces with set 'width' (array or scalar) use the correct bar span.

alexcjohnson · 2017-04-03T13:39:05Z

 return Fx.inbox(di.b - xval, di.x - xval) + (di.x - xval) / (di.x - di.b);
 };
- dy = function(di) {
+ dy = function(di, i) {


I suppose this (providing i as an extra arg) is the most flexible way to handle the issue for future extensibility, but the way that matches better with what we do in scatter - and should be slightly better perf - would be to include the width of each point in di

Yeah. Good call! Post #1519 this will be easy!

alexcjohnson · 2017-04-05T05:08:49Z

 var calcBar = calcTrace[j];

+ // store the actual bar width and position, for use by hover
+ var width = calcBar.w = (barwidthIsArray) ? barwidth[j] : barwidth;


I suspect we could clean up the hover routine quite a bit more if we stopped using .x and .y in calcdata... then we'd only have to switch at the beginning of the routine "are xval and yval position and size or vice versa" but I wasn't sure what the consequences of that would be beyond hover, just adding one more value was safe and easy.

alexcjohnson · 2017-04-05T05:13:18Z

+ * Nearly always it's the group that matters, but in case the bar
+ * was explicitly set wider than its group we'd better accept the
+ * whole bar.
+ */


fixes the "compare" part of #1317 - at least if the bar is wider than our default. I guess if it's narrower and there are other things on the plot, we could be accepting this point when we shouldn't be... maybe I'll look at that case tomorrow and see if I can trigger it.

Alright, the only case I can see where this pops up is an explicitly narrow (width<1) single bar with other things on the plot as well, like:
vardata=[{type: 'bar',x: [1],y: [2],width: 0.1},{x:[1.1],y:[1]}];varlayout={xaxis: {range: [-2,2]}};Plotly.newPlot(gd,data,layout);
then the hoverable region for the bar is so wide it actually extends past the scatter point. But the scatter point still wins when you'd want it to. So if that's all it is, I don't feel like it's worth addressing this very obscure edge case, it'd be just as likely to cause other problems.

I agree with ⬆️ . Thanks for documenting it!

alexcjohnson · 2017-04-05T05:14:05Z

 // so you see them continue if you drag the plot
 var p0 = di.p + ((poffsetIsArray) ? poffset[i] : poffset),
- p1 = p0 + ((barwidthIsArray) ? barwidth[i] : barwidth),
+ p1 = p0 + di.w,


a little follow-on benefit of adding di.w

alexcjohnson · 2017-04-05T13:36:48Z

@etpinard back to you for review. Do the tests I added satisfy the TODO up top?

etpinard · 2017-04-05T15:01:49Z

@alexcjohnson

Do the tests I added satisfy the TODO up top?

Absolutely.

💃 thanks for wrapping this one up 🎉

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

etpinard added 3 commits March 17, 2017 17:25

make distance fn accept pt index as arg
7a4154f

generalize bar delta computation
c84e2a9
- so that traces with set 'width' (array or scalar) use the correct bar span.

add two bar hover cases with set 'width'
591bd9e

etpinard added status: in progress bug something broken labels Mar 29, 2017

etpinard added this to the v1.26.0 milestone Mar 29, 2017

alexcjohnson reviewed Apr 3, 2017
View reviewed changes

alexcjohnson added 2 commits April 4, 2017 17:15

Merge branch 'master' into bar-width-hover
b34d9ef

broaden bar hover acceptance, and test
30bc8c7

alexcjohnson reviewed Apr 5, 2017
View reviewed changes

shift new bar hover test for ci
06097d7

alexcjohnson added status: reviewable and removed status: in progress labels Apr 5, 2017

alexcjohnson merged commit ce06ea9 into masterApr 5, 2017

alexcjohnson deleted the bar-width-hover branch April 5, 2017 15:16

Uh oh!

Uh oh!

Conversation

etpinard commented Mar 29, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcjohnson commented Apr 5, 2017

Uh oh!

etpinard commented Apr 5, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

etpinard commented Mar 29, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcjohnson commented Apr 5, 2017

Uh oh!

etpinard commented Apr 5, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

etpinard commented Mar 29, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

etpinard commented Mar 29, 2017•
edited
Loading

etpinard commented Mar 29, 2017•
edited
Loading

etpinard commented Mar 29, 2017•
edited
Loading

etpinard commented Mar 29, 2017•
edited
Loading