Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

artist.set_picker(False) no longer keeps artists pickable #19031

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

Draft
wants to merge 1 commit into
base: main
Choose a base branch
Loading
from

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Nov 27, 2020

The documentation for set_picker currently states that None disables
picking, True enables picking, and a custom callable implements, well,
custom picking behavior. It turns out that False also enables
picking, because the relevant check is implemented in Artist.pickable,
which strictly checks picker is not None (and also checks that the
artist has been added to a figure). This can indeed be verified with

from pylab import *
plot([1, 2], picker=False); gcf().canvas.mpl_connect("pick_event", print)

and clicking on the line. Strictly speaking, the docs state nothing
about False, so the behavior does not violate the docs, but that's
clearly non-optimal behavior, which I'm proposing to change here.

PR Summary

PR Checklist

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

The documentation for `set_picker` currently states that `None` disables
picking, `True` enables picking, and a custom callable implements, well,
custom picking behavior.  It turns out that `False` *also* enables
picking, because the relevant check is implemented in `Artist.pickable`,
which strictly checks `picker is not None` (and also checks that the
artist has been added to a figure).  This can indeed be verified with
```python
from pylab import *
plot([1, 2], picker=False); gcf().canvas.mpl_connect("pick_event", print)
```
and clicking on the line.  Strictly speaking, the docs state nothing
about `False`, so the behavior does not violate the docs, but that's
clearly non-optimal behavior, which I'm proposing to change here.
@anntzer anntzer added this to the v3.4.0 milestone Nov 27, 2020
@QuLogic
Copy link
Member

QuLogic commented Nov 28, 2020

The deprecated call of .set_picker(0) would enable picking and set pickradius to 0, but now it will disable picking, no?

@anntzer
Copy link
Contributor Author

anntzer commented Nov 28, 2020

Fair point. Do you think this warrants a deprecation period? In which case the whole PR should perhaps be turned into a deprecation of the old behavior rather than fully modifying it as it does right now.

@jklymak
Copy link
Member

jklymak commented Dec 15, 2020

Is there a practical difference between a pick or radius zero and turning it off?

@anntzer
Copy link
Contributor Author

anntzer commented Dec 15, 2020

I think so? For a filled rectangle even with pickradius=0 you should be able to pick it anywhere in the rectangle.

@timhoffm
Copy link
Member

timhoffm commented Dec 15, 2020

Also I suppose, for a line with pickradius 0 you can still pick it by clicking exactly on the pixel of that line? Apparently not.

Copy link
Member

@tacaswell tacaswell left a comment

Choose a reason for hiding this comment

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

Restarted appveyor.

Anyone can merge on CI green.

@QuLogic QuLogic added the status: needs comment/discussion needs consensus on next step label Dec 19, 2020
@QuLogic
Copy link
Member

QuLogic commented Dec 19, 2020

I'm not sure if the discussion is finished?

@anntzer
Copy link
Contributor Author

anntzer commented Dec 19, 2020

We may want to resolve #19039 first, indeed.

@QuLogic QuLogic modified the milestones: v3.4.0, v3.5.0 Jan 28, 2021
@jklymak jklymak marked this pull request as draft April 23, 2021 16:59
@QuLogic QuLogic modified the milestones: v3.5.0, v3.6.0 Aug 21, 2021
@QuLogic QuLogic modified the milestones: v3.6.0, v3.7.0 Jul 5, 2022
@tacaswell tacaswell modified the milestones: v3.7.0, v3.8.0 Dec 16, 2022
@ksunden ksunden modified the milestones: v3.8.0, future releases Aug 8, 2023
Copy link

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Nov 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: inactive Marked by the “Stale” Github Action status: needs comment/discussion needs consensus on next step status: needs rebase
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.