You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wishlist: a "copy image to clipboard" button in the Toolbar for interactive backends.
For the wx backend, I've had some success with adding such a button by altering the function matplotlib.backends.NavigationToolbar2Wx._init_toolbar() in backend_wx.py so that the last line:
Seems like a nice idea, and should be doable in all of the backends. Not sure we'll get to this before 1.3, but if you want to have a crack at it, I can help as able.
I will add my usual curmudgeonly caution: I'm not sure it is a good idea to keep piling things into the toolbars, and adding backend-specific code. I would prefer to see this sort of thing be strictly optional, and ideally not part of core mpl.
@efiring - I'm sympathetic with the philosophy to keep the toolbar uncluttered, but I believe the copy-to-clipboard command is nearly universal across gui programs which handle images, and may be an acceptable exception even to many sharing this philosophy.
I'm interested in the comment that a gui button can be optional. Has that already been implemented? What optional buttons are available that I don't yet know about?
The addition of toolbar buttons of course must be backend-specific, but I'm sure the actual "copy" function could be made backend-independent. Perhaps as a method of Figure?
How about adding a keyboard shortcut? ctrl+c is pretty ubiquitous...
It'd be nice if this were a method on the figure (or some other suitable place) which did not need to know about the backends/OS etc. - perhaps https://github.com/gfxmonk/pyperclip might be useful. If not, I propose starting a new repo which provides copy (and paste) capabilities in a cross platform & cross windowing toolkit way which matplotlib can make use of.
pyperclip comes close. We would need to add a few backends that we have that it doesn't (tk and wx, for example). It imports GUI frameworks to do what it does, and importing multiple gui frameworks at the same time can cause all kinds of strange conflicts, so we'd need to make sure it never imports something that matplotlib hasn't already imported. It also seems to only deal with setting text to the clipboard, not binary images, but that's probably also fixable.
I think ultimately, the backends are going to have to handle this, though. It might be possible to copy from an Agg backend in a backend-agnostic way, but if the rendering is being handled by the GUI framework, (Gtk, Wx and Mac OS-X) the method used to retrieve the buffer and put it in the clipboard will be different. I think it's cleanest to just put this in the backends. That doesn't mean we can't put a method on the figure that delegates to the backend, though, and from the user's point of view, it's an operation on the figure.
If everybody agrees, at the same time of implementing all the backends for MEP22, I can add this as a default Tool, of course without button, just with the ctrl+c shortcut,
ctrl-C seems problematic as a universal "copy" shortcut. On the Mac it is cmd-C. In typical linux terminals it is shift-ctrl-C because ctrl-C is of course the classic "abort", or KeyboardInterrupt in python. I suppose you could still use ctrl-C in the figure window, though. The user just has to be sure that window has focus.
Many of the GUI frameworks have ways of getting the default key shortcuts for common operations like this. We should at least use those as the default. For example, in Qt (scroll down to standard shortcuts):
Why rcsetup doesn't have a validation against OS/framework?
As far as I can see, the option so far has been to include everything in the strings, for example 'keymap.quit': [('ctrl+w', 'cmd+w'), validate_stringlist], instead of checking witch one is available for the current OS/framework.
If this is considered an acceptable practice, in that case I would suggest to add 'keymap.copy': [('ctrl+c', 'cmd+c', 'shift+ctrl+c'),validate_stringlist ] to rcParams
@thomasaarholt yes indeed this is useful.
The reason I didn't add it as default tool is... (I'm ashamed) is because I wasn't able to get it to work with Tkinter 😊 .
The default tools have to be available in all the backends. At this moment the Toolmanager is working with Gtk3 and Tkinter, so if we want this to be added, we have to make Tkinter's version.
If you can help out and get it to work with Tkinter, then we can add it, and in that way, we force all other backends to have it also (when they are being ported).
@fariza, I am only just beginning to get to know Python as a developer, and in the writing-up stage of my PhD. :) (It was due to the last bit that I realised that it might be a useful feature) After I've finished my thesis, I'd love to take a look!
Activity
mdboom commentedon May 9, 2013
Seems like a nice idea, and should be doable in all of the backends. Not sure we'll get to this before 1.3, but if you want to have a crack at it, I can help as able.
efiring commentedon May 9, 2013
I will add my usual curmudgeonly caution: I'm not sure it is a good idea to keep piling things into the toolbars, and adding backend-specific code. I would prefer to see this sort of thing be strictly optional, and ideally not part of core mpl.
ryggyr commentedon May 10, 2013
@efiring - I'm sympathetic with the philosophy to keep the toolbar uncluttered, but I believe the copy-to-clipboard command is nearly universal across gui programs which handle images, and may be an acceptable exception even to many sharing this philosophy.
I'm interested in the comment that a gui button can be optional. Has that already been implemented? What optional buttons are available that I don't yet know about?
The addition of toolbar buttons of course must be backend-specific, but I'm sure the actual "copy" function could be made backend-independent. Perhaps as a method of Figure?
pelson commentedon May 10, 2013
How about adding a keyboard shortcut?
ctrl+cis pretty ubiquitous...It'd be nice if this were a method on the figure (or some other suitable place) which did not need to know about the backends/OS etc. - perhaps https://github.com/gfxmonk/pyperclip might be useful. If not, I propose starting a new repo which provides copy (and paste) capabilities in a cross platform & cross windowing toolkit way which matplotlib can make use of.
mdboom commentedon May 10, 2013
pyperclipcomes close. We would need to add a few backends that we have that it doesn't (tk and wx, for example). It imports GUI frameworks to do what it does, and importing multiple gui frameworks at the same time can cause all kinds of strange conflicts, so we'd need to make sure it never imports something that matplotlib hasn't already imported. It also seems to only deal with setting text to the clipboard, not binary images, but that's probably also fixable.I think ultimately, the backends are going to have to handle this, though. It might be possible to copy from an Agg backend in a backend-agnostic way, but if the rendering is being handled by the GUI framework, (Gtk, Wx and Mac OS-X) the method used to retrieve the buffer and put it in the clipboard will be different. I think it's cleanest to just put this in the backends. That doesn't mean we can't put a method on the figure that delegates to the backend, though, and from the user's point of view, it's an operation on the figure.
pelson commentedon May 13, 2013
Mmmm. I'm inclined to agree. Thanks for the insight @mdboom.
tacaswell commentedon Jan 17, 2014
This is an obvious addition to the
Toolslibrary in MEP22.fariza commentedon Jan 22, 2014
Added a
CopyToolin the exampleexamples/user_interfaces/navigation.pyof MEP22https://github.com/matplotlib/matplotlib/wiki/Mep22#branches-and-pull-requests (I don't know if it is the right way to do it, but it seems to work).
Does anybody has a proposal to handle default (optional) Tools?
rcParamsNavigationto modify the default ToolsTool, to set default toolsfariza commentedon Jan 27, 2014
If everybody agrees, at the same time of implementing all the backends for MEP22, I can add this as a default Tool, of course without button, just with the
ctrl+cshortcut,efiring commentedon Jan 27, 2014
ctrl-Cseems problematic as a universal "copy" shortcut. On the Mac it iscmd-C. In typical linux terminals it isshift-ctrl-Cbecausectrl-Cis of course the classic "abort", or KeyboardInterrupt in python. I suppose you could still usectrl-Cin the figure window, though. The user just has to be sure that window has focus.mdboom commentedon Jan 27, 2014
Many of the GUI frameworks have ways of getting the default key shortcuts for common operations like this. We should at least use those as the default. For example, in Qt (scroll down to standard shortcuts):
http://qt-project.org/doc/qt-4.8/qkeysequence.html
I recall Gtk having similar facilities, though I can't find the docs atm.
fariza commentedon Jan 28, 2014
Ups... I didn't realize the problem.
I guess this will have to wait until we have a method to find this shortcuts for each backend.
I wasn't able to find it for GTK, I posted a question on SO....
fariza commentedon Jan 30, 2014
Why rcsetup doesn't have a validation against OS/framework?
As far as I can see, the option so far has been to include everything in the strings, for example
'keymap.quit': [('ctrl+w', 'cmd+w'), validate_stringlist],instead of checking witch one is available for the current OS/framework.If this is considered an acceptable practice, in that case I would suggest to add
'keymap.copy': [('ctrl+c', 'cmd+c', 'shift+ctrl+c'),validate_stringlist ]torcParams2 remaining items
thomasaarholt commentedon Jan 13, 2016
Could I bring this back from the silence? This would still be useful.
fariza commentedon Jan 13, 2016
@thomasaarholt yes indeed this is useful.
The reason I didn't add it as default tool is... (I'm ashamed) is because I wasn't able to get it to work with Tkinter 😊 .
The default tools have to be available in all the backends. At this moment the Toolmanager is working with Gtk3 and Tkinter, so if we want this to be added, we have to make Tkinter's version.
If you can help out and get it to work with Tkinter, then we can add it, and in that way, we force all other backends to have it also (when they are being ported).
thomasaarholt commentedon Jan 14, 2016
@fariza, I am only just beginning to get to know Python as a developer, and in the writing-up stage of my PhD. :) (It was due to the last bit that I realised that it might be a useful feature) After I've finished my thesis, I'd love to take a look!
fariza commentedon Jun 3, 2017
@marcwell as I said before, I am waiting for volunteers to implement the tool for other backends. So far I have only Gtk3
smcinerney commentedon Feb 12, 2018
and StackOverflow post https://stackoverflow.com/questions/3571117/customizing-matplotlib-image-display-to-add-copy-paste
fariza commentedon Feb 13, 2018
I just started the work on the implementation, I need help for QT and TK... volunteers?
timhoffm commentedon Feb 13, 2018
I could do the Qt part at some point. But not before in a month or so. So if someone else is quicker, go for it.
jklymak commentedon Jul 28, 2020
#10446 is merged - I'll close this as done, but feel free to re-open if I'm misunderstanding....