Skip to content

ColorbarAxes is an imperfect proxy for the Axes passed to Colorbar #20479

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.

Sign up for GitHub

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

Jump to bottom
Closed
richardsheridan opened this issue Jun 22, 2021 · 3 comments · Fixed by #20501
Closed

ColorbarAxes is an imperfect proxy for the Axes passed to Colorbar #20479

richardsheridan opened this issue Jun 22, 2021 · 3 comments · Fixed by #20501
Labels
topic: color/colorbar
Milestone
v3.5.0

Comments

@richardsheridan
Copy link
Contributor

Bug report

Bug summary

Before the refactor, one would set colorbar axes to be pickable with colorbar.ax.set_picker(True). Now, it is necessary to use the undocumented colorbar.ax.inner_ax.set_picker(True). Likewise, with motion notify events, MouseEvent.inaxes is not colorbar.ax under any circumstances, it always is colorbar.ax.inner_ax.

But, this is not really about events so much as the fact that Colorbar(ax).ax is ax == False and all methods of colorbar.ax are actually bound to a different object, namely colorbar.ax.inner_ax, so they are acting on surprising, hidden state (from a user's perspective).

We could work around the events issue, but I feel like there would be an ongoing stream of bug reports without a comprehensive fix. On the other hand, I definitely don't want to revert ColorbarAxes entirely because I really like the improvements that it enabled.

Code for reproduction

Please see #20471, which this issue blocks (in my opinion).

Matplotlib version

  • Operating system: Win10
  • Matplotlib version (import matplotlib; print(matplotlib.__version__)): master
  • Matplotlib backend (print(matplotlib.get_backend())): tkagg
  • Python version: 3.8.8
  • Jupyter version (if applicable):
  • Other libraries:

cc @jklymak
@richardsheridan richardsheridan mentioned this issue Jun 22, 2021
Merged
7 tasks
@jklymak
Copy link
Member

jklymak commented Jun 22, 2021

Thanks @richardsheridan we should sort this out, but do you have short scripts that cause problems without requiring interactivity? I'm a little confused, without looking carefully, why the methods have not been passed to the parent. That was certainly the intent.

@jklymak
Copy link
Member

jklymak commented Jun 22, 2021

So just to be clear

fig, ax = plt.subplots()
pc = ax.pcolormesh(np.random.randn(30, 30))
cb = fig.colorbar(pc, ax=ax)
cb.ax == ax  # returns False

has always returned False. ax is the axes that the colorbar is placed, not the parent axes (ax) that made room for the colorbar.

It is also true that cb.ax.set_xlabel == cb.ax.inner_axes.set_xlabel is False, but they do the same thing.

What is incorrect is that the colorbar axes never gets added to the axes stack on the figure, so it can't register events. Adding it to the figure axes stack makes it recognize axes_enter_event and axes_leave_event. It also does the right thing for button_press_event. What it fails to register is a pick_event properly. However, I'm confused, because I could not get a pick_event to register anywhere on the canvas, so maybe it is just my backend...

@anntzer
Copy link
Contributor

anntzer commented Jun 22, 2021

I think I have a patch for pick_event, but it would depend on cb.ax correctly getting added to the artist tree, which, as you note, isn't the case currently.

This was referenced Jun 22, 2021
Closed
Merged
@QuLogic QuLogic added this to the v3.5.0 milestone Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: color/colorbar
Projects
None yet
Milestone
v3.5.0
4 participants
@QuLogic @anntzer @jklymak @richardsheridan