Fix AxesWidgets on inset_axes that are outside their parent. #29966
Conversation
|
Kindly bumping. |
|
The new test does not already fail on |
When axes are overlapping, LocationEvent.inaxes can point not to the axes we care about, but to another one. Widgets currently recompute location event axes coordinates relative to the axes to which the widget is assigned, but this recomputation code was previously brittle wrt. events that are outside the axes they wrongly believe they belong to (so x/ydata is None), even though they are indeed within the axes they actually belong to. This can occur when a widget is associated with an "inset_axes" that's actually outside the parent axes. A practical case is given by ```python from pylab import * ax = figure(layout="constrained").add_subplot() ax1 = ax.inset_axes([0, 1, 1, .25], sharex=ax) ss = mpl.widgets.SpanSelector(ax1, print, "horizontal") show() # try to trigger the spanselector ``` which would raise an exception prior to this patch. Improve the recomputation logic by fully reparenting the event passed to the widget to the correct parent axes from the onset.
|
Ah, good catch. Actually that's basically due to the issue fixed by #29993: originally, the tests were written by directly invoking the widget methods with a fully synthetic event with the relevant attributes already properly set, but the bug occurs because the event-generation machinery doesn't actually set |
| # move outside of axis | ||
| x, y = target.transData.transform((199, 199)) | ||
| MouseEvent('motion_notify_event', ax.figure.canvas, x, y, button=1)._process() | ||
| do_event(tool, 'release', xdata=250, ydata=250, button=1) |
There was a problem hiding this comment.
Why leave only one do_event here?
There was a problem hiding this comment.
I was hoping to just do a mass replace of do_event by _from_ax_coords in #29993, and if anything, leaving the do_event there would be useful as a pinned note to remember changing that test as well.
When axes are overlapping, LocationEvent.inaxes can point not to the axes we care about, but to another one. Widgets currently recompute location event axes coordinates relative to the axes to which the widget is assigned (#25555), but this recomputation code was previously brittle wrt. events that are outside the axes they wrongly believe they belong to (so x/ydata is None), even though they are indeed within the axes they actually belong to. This can occur when a widget is associated with an "inset_axes" that's actually outside the parent axes. A practical case is given by
which would raise an exception prior to this patch.
Improve the recomputation logic by fully reparenting the event passed to the widget to the correct parent axes from the onset.
PR summary
PR checklist