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

Fix namelength=0 case + implement namelength to loneHover traces #3734

Merged
merged 8 commits into from
Apr 9, 2019

Conversation

etpinard
Copy link
Contributor

@etpinard etpinard commented Apr 5, 2019

fixes #3728

cc @plotly/plotly_js

@etpinard etpinard added bug something broken status: reviewable labels Apr 5, 2019
@archmoj
Copy link
Contributor

archmoj commented Apr 5, 2019

Looks good me.
@antoinerg @nicolaskruchten any opinion on @etpinard question:

Do you think namelength should (essentially) override < extra > ?

@nicolaskruchten
Copy link
Contributor

I think namelength should do nothing if extra is set in hovertemplate

@alexcjohnson
Copy link
Collaborator

Hmm, I was going to argue the opposite - if you template some field into <extra>, it could still be useful to limit it with namelength. What if we just default to namelength: -1 when hovertemplate is used, but still honor it if provided?

@antoinerg
Copy link
Contributor

antoinerg commented Apr 5, 2019

Hmm, I was going to argue the opposite - if you template some field into <extra>, it could still be useful to limit it with namelength. What if we just default to namelength: -1 when hovertemplate is used, but still honor it if provided?

I think I prefer @alexcjohnson suggestion above. I think it's both useful and more consistent with our current behavior. All hover labels should be stylable in the same way whether they use hovertemplate or not.

@etpinard I just realized that the two functions Fx.(lone|multi)Hover do not call cleanPoint which is where your fix takes place. Therefore, the current PR will not work with sunburst, sankey, parcats, webGL and possibly others. This begs the question: is there any reason we're not calling cleanPoint in functions Fx.(lone|multi)Hover?

@etpinard
Copy link
Contributor Author

etpinard commented Apr 5, 2019

This begs the question: is there any reason we're not calling cleanPoint in functions Fx.(lone|multi)Hover?

Ha, good eye namelength never got implemented for those traces, it looks like.

@nicolaskruchten
Copy link
Contributor

Well, the namelength vs extra nomenclature is odd. Also labelling that widget in the RCE will be interesting if they interact.

I don't have a strong preference.

@antoinerg
Copy link
Contributor

Well, the namelength vs extra nomenclature is odd.

I regret using <extra> as a tag. <name> would have been more appropriate since it literally sets what by default is the trace name in hoverlabels. Should we start supporting both tag names?

As for namelength, it should do what the doc says:

Sets the default length (in number of characters) of the trace name in the hover labels for all traces.

etpinard added 6 commits April 8, 2019 12:07
use it to determine if we coerce `hoverinfo` and `hoverlabel`
in Plots.supplyTraceDefaults
... while making hoverlabel.namelength dflt to -1
    when hovertemplate is set
... that is pie, sankey, sunburst and all gl3d traces
@etpinard
Copy link
Contributor Author

etpinard commented Apr 8, 2019

This PR is ready again for review.


What if we just default to namelength: -1 when hovertemplate is used, but still honor it if provided?

Done in e9f8403

Therefore, the current PR will not work with sunburst, sankey, parcats, webGL and possibly others.

namelength should now work for all our trace type that support hoverlabel.* thanks to 918d22e and 7f1645d

@etpinard etpinard added this to the v1.47.0 milestone Apr 8, 2019
@@ -70,6 +71,7 @@ function render(scene) {
if(lastPicked !== null) {
var pdata = project(scene.glplot.cameraParams, selection.dataCoordinate);
trace = lastPicked.data;
var traceNow = gd._fullData[trace.index];
Copy link
Contributor

Choose a reason for hiding this comment

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

@etpinard Could you please describe why traceNow is needed here?
Thanks in advance.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because hoverlabel.* edits don't (and shouldn't have to) replot the scene. As Plots.supplyDefaults creates new gd._fullData and gd._fullLayout refs on every call, we need to use the right "now" trace object when hovering.

@antoinerg
Copy link
Contributor

antoinerg commented Apr 8, 2019

Thanks for all the tests! It looks good to me and I think it is ready to go. I will let @archmoj give you a dancer if he is satisfied with your answer.

Absolutely non-blocking but could you set hoverlabel.namelength to -1 in the mock sunburst_values to make sure the hover labels stay the same? Right now the trace names are clipped.

@archmoj
Copy link
Contributor

archmoj commented Apr 9, 2019

@etpinard thanks for the PR.
💃
Also - To help Q&A you may modify the PR description & briefly describe what it does.

@etpinard etpinard changed the title Fix namelength=0 case Fix namelength=0 case + implement namelength to loneHover traces Apr 9, 2019
@etpinard etpinard merged commit adf7ca2 into master Apr 9, 2019
@etpinard etpinard deleted the namelength-zero-fix branch April 9, 2019 01:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something broken
Projects
None yet
Development

Successfully merging this pull request may close these issues.

hoverlabel.namelength = 0 should hide the extra hoverlabel thing
5 participants