-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Emit a plotly_relayout' event upon mouseup, wheel #466
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
Emit a plotly_relayout' event upon mouseup, wheel #466
Conversation
}; | ||
|
||
scene.glplot.canvas.addEventListener('mouseup', relayoutCallback.bind(null, scene)); | ||
scene.glplot.canvas.addEventListener('wheel', relayoutCallback.bind(null, scene)); |
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.
Great. It would be nice to add a mouse wheel test. See the legend_scroll for inspiration.
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.
Thanks for the feedback!
18e4954
to
5180356
Compare
mouseEvent('mousedown', 110, 150); | ||
mouseEvent('mousemove', 220, 150); | ||
mouseEvent('mouseup', 220, 150); | ||
|
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.
@etpinard @bpostlethwaite In this non-WebGL case, it's been fairly straightforward to simulate the panning activity by the user (to check if plotly_relayout is emitted, and layout on DIV is changed properly). However the analogous thing on scattergl (WebGL based) doesn't yield as easily; my suspicion is that it's more demanding, maybe needing more than the clientX / clientY coordinates. I've blindly tried additionally simulating mouseenter, mouseover etc. in gl_plot_interact_test.js
but it didn't help. I'm pushing on happily with that but if either of you have any memory about gl mouse magic, it might obviate the need to step through event handling.
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.
maybe needing more than the clientX / clientY coordinates.
Not sure if you've tried that yet, but here's how I made the plotly_click
test work in gl3d.
36a571f
to
5f0a4f0
Compare
… lint incompatibilities
… lint incompatibilities
…changes on the DIV via unit testing
…oHaveBeenCalledTimes
5f0a4f0
to
19c478d
Compare
lastInputTime: scene.camera.lastInputTime, // helps determine which one is the latest input (if async) | ||
xrange: xrange.slice(0), | ||
yrange: yrange.slice(0) | ||
}; |
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.
In gl2d, scene
is purely internal. I'd vote for something like:
update = {
lastInputTime: scene.camera.lastInputTime // great idea here!
};
update[xaxis._name] = xrange.slice();
update[yaxis._name] = yrange.slice();
where ?axis.name
will be xaxis
, xaxis2
, yaxis
, yaxis2
...
|
||
var MODEBAR_DELAY = 500; |
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.
do we really need this in SVG graphs?
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.
@etpinard this is needed as the callback turns out to be deferred - the tests pass if I set it to 0, but fail if I unroll the setTimeouts into the main loop (callback has been called 0 times).
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.
Makes sense. Thanks!
@monfera Looking good. I've made one blocking #466 (comment). Looking forward to merging this. |
… has changed, in sync with the plotly_relayout event
…the data structure of the callback.
@@ -174,6 +174,7 @@ function initializeGLPlot(scene, fullLayout, canvas, gl) { | |||
var relayoutCallback = function(scene) { | |||
var update = {}; | |||
update[scene.id] = getLayoutCamera(scene.camera); | |||
scene.saveCamera(scene.graphDiv.layout); |
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'm ok with this here.
BUT we should add a comment in the resetCameraLastSave
mode bar button handler.
That handler looks in the un-updated fullLayout.scene.camera
object to reset the camera to the last saved position.
@monfera Great. I'll merge this after:
|
@@ -350,6 +350,8 @@ function handleCamera3d(gd, ev) { | |||
|
|||
if(attr === 'resetDefault') scene.setCameraToDefault(); | |||
else if(attr === 'resetLastSave') { | |||
// This handler looks in the un-updated fullLayout.scene.camera object to reset the camera | |||
// to the last saved position. |
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.
thanks!
…ing it; test case refactor for multiple mocks, fewer globals and explicit async steps
743b6b7
to
7c23e2e
Compare
…ed by CI. The plan is to move more and more tests here, i.e. continuously improve on testing coverage. This test file purposefully avoids beforeEach and afterEach to favor a simpler to follow data flow (no globals).
…t of having two files is that this new file is expected to pass reliably on a local non-headless jasmine run. So we should put more and more (reliable) test cases into this one so that test coverage for at least local automated testing is increasing, even though they're excluded from CI.
// The teardown function needs information of what to tear down so afterEach can not be used without global vars. | ||
// In addition to removing the plot from the DOM it also destroy possibly present 2D or 3D scenes | ||
|
||
// TODO we should figure out something to only rely on public API calls |
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.
@etpinard if you have a suggestion for using a public API call for the destroy procedure, I'm glad to switch to it. In any case, general feedback is useful as it's a slightly different way of teardown compared to the global var + afterEach method. The purpose is to be as local about state management as possible, i.e. fewer conventions such as the gd global.
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.
Oh. Plotly.purge
should do the trick. It was added back in #300
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.
@etpinard awesome, I'll switch to that in both the old and the new GL interaction test files. Although maybe it should be incorporated in the test helper destroy_graph_div
to more easily catch all uses, let's see.
Great PR 🍻 Thanks for helping us bring our gl3d tests suite up to speed. My comment above about |
@etpinard cheers :-) |
Fixes #FI-30.