@ericpre - the extents of the selector always refer to the bottom left and top right of the rectangle, regardless of the order of the actual clicking. Sometimes you need to know the direction in which the rectangle was drawn, so you need to differentiate between click and release. If you want the extent, call extent.

@ericpre - the extents of the selector always refer to the bottom left and top right of the rectangle, regardless of the order of the actual clicking. Sometimes you need to know the direction in which the rectangle was drawn, so you need to differentiate between click and release. If you want the extent, call extent.

Yes, the issue is that onselect now has to use eventpress and eventrelease and this is what is useless when using the handles. With this is PR, it is not possible to use extents in the onselect callback function.

This is not passing the doc build. Also please rebase on master if you know how to do that.

Yes, the issue is that onselect now has to use eventpress and eventrelease and this is what is useless when using the handles. With this is PR, it is not possible to use extents in the onselect callback function.

I don't understand the problem. Just sort the coordinates if you need them strictly increasing in the callback? Sorting them before passing to the callback reduces the possible usage.

This is not passing the doc build. Also please rebase on master if you know how to do that.

I haven't touched any of the docs for this function/file (afaik). How is it failing/where do I need to read about building docs? I don't know about rebasing on master.

Yes, the issue is that onselect now has to use eventpress and eventrelease and this is what is useless when using the handles. With this is PR, it is not possible to use extents in the onselect callback function.

I don't understand the problem. Just sort the coordinates if you need them strictly increasing in the callback? Sorting them before passing to the callback reduces the possible usage.

Sorry, I was not very clear. When using a selector on an axis, I would expect that in the callback that I get the current selection, as it is for example in the case of the SpanSelector with onselect(min, max). With this PR, the onselect signature will match the current selection only when used with interactive=False or for a new selection only when interactive=True. Any changes to the selection using handles will not provide the selection. See for example:

import matplotlib.pyplot as plt
from matplotlib.widgets import RectangleSelector


def onselect(eclick, erelease):
    print("onselect callback triggered")
    print("Press event: ", eclick.xdata, eclick.ydata)
    print("Release event: ", erelease.xdata, erelease.ydata)

fig = plt.figure()
ax = fig.add_subplot()
ax.plot([0, 10], [0, 20])

rs = RectangleSelector(ax, onselect, interactive=True)

will give the following output:

onselect callback triggered
Press event:  2.493951612903226 15.32142857142857
Release event:  5.709677419354839 5.142857142857142
onselect callback triggered
Press event:  5.6875 10.261904761904761
Release event:  6.818548387096775 10.142857142857142

The last press and release events can't be used to retrieve the data selection.

This comes back to my initial question. To make it conditional on interactive, or to just expect users to have an explicit call to extents to get the size of the current selection?

In my opinion, using the extent makes more sense and is consistent with the SpanSelector. Please correct me if I am wrong, but I don't see what could be the advantage of using eventpress and eventrelease in favour of the extent: the extent will also reports the correct selection range while the events press/release will not.
The only sense I can make of the current implementation is that it was implementated before interactive and before that, it was behaving correctly. interactive has been implemented for a while now and I guess the behaviour of onselect has never been adjusted accordingly, i. e. to report correct selection range in any situation.

Related to my comment in #9608 I am 👎🏻 on merging this as is.

I think @ericpre 's point about the interteractive case in very strong that in interactive mode you expect to get back the corners of rectangle, not necessarily the point the user just clicked on (eg, when they dragged on the edge) as the thing of interest is the "rectangle area". By just returning the point the user release on they won't get that anymore.

A case could be made for remembering the "first" corner and the "release" corner on the initial selection and then normalizing to that so onselect always gets to opposite corners of a rectangle at their full extent, however that seems like a fair amount of book-keeping / logic to get right and it would be changing behavior that has stood for 4+ years and runs the risk of breaking a different set of users.

As I mentioned in #9608 I think the best course of action here is to

1. update the documentation to describe the behavior
2. implement a VectorSelector with handles and the whole 9 yards to handle to use case that the original poster had

@rowlesmr Even though we are having a mostly critical response to your work, please do not be discouraged! We appreciate your time and effort and hopefully will end up someplace that is better than either the status quo or your initial proposal.

I've moved to draft but feel free to move back...

Hi @rowlesmr - are you interested in continuing this work? If so, please mark the PR as ready for review and let us know if you need help with the rebase, we have instructions for that here. Thanks!