Heatmap mouseover #496
Heatmap mouseover #496
Conversation
Add factory function to generate functions to return a label based on a list given a float coordinate.
Display (x=xlabel, y=ylabel, z=val)
Display (x=xlabel, y=ylabel, z=val) as cursor is moved around plot
|
This isn't something that can be handled on your end? Seaborn is likely not the only place people are going to want to use categorical labels on the axes of a |
|
This works for me but could the implementation of showing the z value here not clash with matplotlib/matplotlib#3989 ? |
|
mpl does not capture enough semantic information to be able to reliably tell when the user is plotting categorical data or not. That knowledge is captured at the seaborn level (by which functions are being used) so this formatting should live downstream. Eventually the z-data should move upstream, but reporting the x and y position as labels should not. @michaelaye If you are using a version of mpl with matplotlib/matplotlib#3989 you will get this plus the artist specific string on the end. The brains to modulate if the I thought about just doing the x and y values, but figured that you would also want the z value now rather than some time this summer 😉 . |
Perhaps not automatically, but as an option in |
|
Or alternatively there is already the |
|
Similarly, I am unenthusiastic about mpl absorbing lots of shims to deal with domain-specific assumptions. I view I am some what surprised you don't use any of the interaction. That is leaving a tremendous amount of the mpl's power on the table. |
|
Then I suppose we are at an impasse. |
|
I'll apologize for my hasty solution in matplotlib/matplotlib#4302 that perhaps "gave hope" to this being a simple bug. I think @tacaswell's descriptions make it clear why this isn't so easy and that, at least currently, seaborn has the semantic knowledge to do this in the right way but matplotlib doesn't. To give some context, matplotlib I think historically has been burned by "assuming too much" in some of its interfaces, and while we can make changes on the matplotlib end to handle this other third-party tools may not agree. I would be nice to step back and find a way forward here... Perhaps as a way of comparing apples to apples, we already have a sense of what this looks like to solve it on the seaborn end in this PR. What would this look like to solve on the matplotlib end -- and how, specifically, would it limit matplotlib's API flexibility in the future? I think an implementation might clarify those points. |
Closes #495 for real.