Skip to content
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

Hover / unhover events on the 2d WebGL plots #994

Merged
merged 10 commits into from
Oct 5, 2016
Merged

Conversation

monfera
Copy link
Contributor

@monfera monfera commented Sep 29, 2016

Covers plotly_hover, plotly_unhover, plotly_click.

#743
Also: FI-71
Partial coverage: #130

@etpinard etpinard added this to the v1.18.0 milestone Sep 29, 2016
Copy link
Contributor

@etpinard etpinard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@monfera this is looking great. Thanks for doing into this!

Are you planning on adding plotly_click event in this PR too?

color: nextSelection.color,
name: nextSelection.name,
hoverinfo: nextSelection.hoverinfo,
screenCoord: nextSelection.screenCoord.slice()
Copy link
Contributor

@etpinard etpinard Sep 29, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh nice. That looks pretty useful.

But I would prefer aiming for parity with cartesian event data as listed here for now.

Referencing #988

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about it but it didn't look like all the properties were available, so I went for what's there already. I asked your feedback on a feel that you might want something else :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@etpinard just to clarify, you want to be as close to the data contents of the event emission in the SVG version as possible, correct? E.g.
image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes exactly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@etpinard any advice on how to approach this? I just reviewed the code that needs to execute for this data to be available: around 350 lines in fx.hover

Do you think it's possible to make it work just by invoking it from within scene2d, or it's doable but maybe some parts of it need to be refactored / conditionalized, or I should perhaps extract out some useful small subset of it?

It looks like quite a large piece of interdependent functionality, those hundreds of lines in that block are there for a reason, and I'd rather not waste time speculatively in the wrong direction if you perhaps have some conviction about which way to go. My wishful thinking is that it feels directly reusable to you without much change :-)

In the absence of this, maybe we can even break the task apart for quick mergeability, e.g. putting in the most essential data first, something similar to what we have now, and making a separate PR for data enrichment that's implemented as DRY as possible, perhaps with a scarily ambitious refactoring of function hover() {...} :-)

Copy link
Contributor

@etpinard etpinard Sep 30, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it's possible to make it work just by invoking it from within scene2d

It's definitively possible. That's how I got mapbox hover labels to work - see here.

But, I would call that outside the scope of this PR.

I think you already have all the info required to produce the same event data object within scene2d, correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all, thanks for pointing me to the Mapbox analogue!

Re your question, if you mean the availability of inputs to Fx.hover from within scene2d.js:

-gd is available

  • subplot just equals to a constant xy for scene2d.js I believe
  • evt isn't available because the DOM mouse event capture is done deeper in the gl-vis stack, but with some work in it probably I can expose it, or I can perhaps reconstruct needed evt data as I already have traceCoords, screenCoords, mouse button info etc. in scene2d.js.

Hopefully I didn't misunderstand your question. What I don't quite understand yet is how it's possible to generate the event data that you ask for (i.e. identical structure and content with the SVG charts) without doing something similar to what you did for Mapbox, because doing so seems to require the execution of most if not all logic in fx.hover.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.. PS. if you meant to ask if I have all the details in scene2d.js to raise a plotly_hover event in identical structure with the SVG counterparts, then the answer is, I'd need to cut and paste so much of what's in fx.hover already that I'd say no :-) i.e. doable and basic inputs are available but would lead to lots of duplication between scene2d.js and graph_interact.js.

// var click = require('../assets/click');
var hover = require('../assets/hover');

describe('Test click interactions:', function() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice tests. But unfortunately, the CircleCI runner still can't boot up gl contexts.

image

Referencing #241

Previously, we ignored the gl test suites in the karma CI config, but more recently, I've been using this hasWebGLSupport util directly in the test suites. See example in the mapbox test - which outputs this

image

making it a little clearer that we're skipping a few tests on CI (I think).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @etpinard, I'll update with the hasWebGLSupport.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, planning to add click to this PR.

@@ -332,6 +337,8 @@ proto.destroy = function() {
this.container.removeChild(this.svgContainer);
this.container.removeChild(this.mouseContainer);

this.fullData = null;
this._inputs = null;
Copy link
Contributor Author

@monfera monfera Oct 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@etpinard I added this.fullData and this._inputs to retain info prerequisite for the event data contents you suggested (below), please let me know if there's a better way. Working on curveNumber and pointNumber now, I suppose these are just the indices.

this.graphDiv.emit('plotly_click', {
                points: [{
                    x: ,
                    y: ,
                    curveNumber: ,
                    pointNumber: ,
                    data: nextSelection.trace._input,
                    fullData: nextSelection.trace,
                    xaxis: this.axis,
                    yaxis: this.yaxis
                }]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very nice.

Copy link
Contributor

@etpinard etpinard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@monfera looking great.

Let's just make sure pointIndex is emitted correctly for trace !== 'scattergl' and this PR will be ✅


var curveIndex = this._inputs[nextSelection.trace.uid];

this.graphDiv.emit(eventType, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

very nicely done.

@@ -128,6 +128,7 @@ proto.handlePick = function(pickResult) {
this.color[index] :
this.color,
name: this.name,
pointIndex: index,
Copy link
Contributor

@etpinard etpinard Oct 3, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great.

Now, can you add pointIndex to pointcloud, heatmapgl and contourgl? Note that for heatmapgl and contourgl, pointIndex will be a 2-item array.

],
textLabel: this.textLabels[index],
name: this.name,
pointIndex: [xIndex, yIndex, zIndex],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer

pointIndex: [xIndex, yIndex]

to match cartesian heatmap and contour

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature something new
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants