8000 Draggable annotations: documentation and bugreport · Issue #5839 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]

Skip to content

Draggable annotations: documentation and bugreport #5839

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

Open
Phlya opened this issue Jan 12, 2016 · 13 comments
Open

Draggable annotations: documentation and bugreport #5839

Phlya opened this issue Jan 12, 2016 · 13 comments
Labels
Documentation keep Items to be ignored by the “Stale” Github Action

Comments

@Phlya
Copy link
Contributor
Phlya commented Jan 12, 2016

Hi, I just found out somewhere on the web that annotations can be set to be draggable by just doing:

plt.annotate(...).draggable()

This is absolutely amazing! But I don't think this is documented anywhere, while it should be (or did I miss it?).

At the same time the behaviour is not perfect: often after dragging one annotation when trying to drag another, the first one would be dragged in the same direction (e.g. I drag the second along x axis, the first one does the same). Sometimes I would get even three annotations moving when I drag one of them.

@tacaswell
Copy link
Member

It is very loosely documented: http://matplotlib.org/examples/pylab_examples/annotation_demo3.html

Odd that it is not in the API docs...

@Phlya
Copy link
Contributor Author
Phlya commented Jan 12, 2016

True, if you carefully look into that example you can realize it...

@tacaswell
Copy link
Member

I agree that it should be much better documented and no one can be blamed for missing it as is.

I only found it by git grep on the source

@Phlya
Copy link
Contributor Author
Phlya commented Jan 13, 2016

What do you think of the bug? Or is it not a bug?

@tacaswell tacaswell added this to the proposed next point release (2.1) milestone Jan 13, 2016
@tacaswell
Copy link
Member

That is probably a bug, it would be worth having a look at the draggable selection logic. @blink1073 has been doing some very interesting / cool work with selection areas, it would be interesting to see if you could re-use any of that to make draggable annotations work better?

@WeatherGod
Copy link
Member

I am not entirely certain, but I think annotations became draggable by
accident via the draggable legend feature. So I guess that that code never
really got fully tested in situations with multiple annotations. Some
example code would be useful. We can then see if it really is a bug or a
feature.

On Wed, Jan 13, 2016 at 8:55 AM, Thomas A Caswell notifications@github.com
wrote:

That is probably a bug, it would be worth having a look at the draggable
selection logic. @blink1073 https://github.com/blink1073 has been doing
some very interesting / cool work with selection areas, it would be
interesting to see if you could re-use any of that to make draggable
annotations work better?


Reply to this email directly or view it on GitHub
#5839 (comment)
.

@Phlya
Copy link
Contributor Author
Phlya commented Jan 13, 2016

Example code:

import numpy as np
import matplotlib.pyplot as plt
x = np.arange(10)
y = x**2
text = [str(i) for i in zip(x, y)]
plt.scatter(x, y)
for a, b, c in zip(x, y, text):
    plt.annotate(c, xy=(a, b), xytext=(a, b+2), arrowprops=dict(arrowstyle="->", color='r', lw=0.5)).draggable()
plt.show()

Try dragging the annotations. Happens randomly, I think, or at least I haven't noticed a pattern.

@twmacro
Copy link
twmacro commented May 12, 2016

I've noticed this behavior too. It does seem mostly random, but I've been able to get repeatable behavior doing this:

  • add two draggable annotations
  • move the second
  • move the first --> the second will move with it

Oddly, if you type a command (I run in IPython with interactive on), it seems to break that link. With more annotations, I noticed that many can be linked and typing a command doesn't break all of them.

One other thing I noticed is that the second step above causes a new ._transform member of the first annotation to be created (I only compared id's of all .__dict__ members ... before and after).

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@anntzer
Copy link
Contributor
anntzer commented Sep 28, 2019

I think the bug was fixed in #10776 (somewhat indirectly); the documentation request remains.

@dstansby
Copy link
Member

Turns out this is the curse of private base classes again

@github-actions
Copy link

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Mar 21, 2023
@QuLogic
Copy link
Member
QuLogic commented Mar 22, 2023

This is unfortunately still undocumented.

@QuLogic QuLogic removed the status: inactive Marked by the “Stale” Github Action label Mar 22, 2023
Copy link

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Mar 25, 2024
@QuLogic QuLogic added keep Items to be ignored by the “Stale” Github Action and removed status: inactive Marked by the “Stale” Github Action labels Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation keep Items to be ignored by the “Stale” Github Action
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants
0