@tacaswell can you help me out finding people with QT/Tk superpowers to help with the implementation for those two backends

http://doc.qt.io/qt-5/qclipboard.html#setImage
http://www.tcl.tk/man/tcl8.5/TkCmd/clipboard.htm
https://wxpython.org/Phoenix/docs/html/wx.Clipboard.html
seem relevant.

@anntzer thanks for the tip, QT was pretty easy

Thetk still pending... HELP!!!

I didn't find a way to do it for tkinter, it seems this is not well supported. So I just emit a warning when called from tk backend

The other option would be to just don't add it in TK, but this means allowing a disparity between backends for default tools. And that is something that we don't really want

@timhoffm I change the message, now it appears in the statusbar

I have just added and tested an implementation for the Wx backends.

I would suggest more consistent names: Qt vs. QT and probably omit theTool prefix for all backends.
As of now it's inconsistent:

backend_tools.ToolRubberband = RubberbandQtbackend_tools.ToolCopyToClipboard = ToolCopyToClipboardQT

@DietmarSchwertberger I agree with the renaming, but it should be done in a separate PR, only for that.
Do you think it would be possible for you to implement what is missing for the WX backend? the toolbar and the modifications of the FigureManager?
It is a little strange to have those tools lying around without using them

@fariza: I've submitted PR#10851 last night for the missing classes.
I have been using the tools before already, but with wx.Button, i.e. the tools were just there to connect canvas and GUI elements.

I would suggest to do the renaming right on this PR, as the names were just introduced.

@DietmarSchwertberger when commiting to other's peoples PR you should open a PR against their branch, not commit directly.
I don't know why github accepted your commit. Normally It shoudn't

@fariza : sorry, I thought this would be the standard approach as anntzer suggested this on a previous PR of him.

It's OK if the PR owner gives you ("verbal") permission to do so (which I gave to all devs for justmy own PRs).

Don't worry, I just wasn't expecting that

@anntzer@timhoffm Is something missing?

See#10851 (comment).

I did only test those parts that were used by the wx implementation and things worked as expected.

I agreee with anntzer that some automated testing for the toolmanager tools is required, but we need a volunteer for that.
This PR, the help tool and the wxToolManager are waiting to be merged.
I don't think that we should wait for the testing as this would slow down ToolManager development quite a lot. Is there a plan to make ToolManager the default? 3.1? By then, testing needs to be in place. For now, I think it's more useful to have the code in master where people can actually use and test it.

@fariza I recently found the "Customize" tool of theNavigationToolbar2QT. Do you plan to implement such a tool for the ToolManager? I could contribute the code for the Wx backends, but I won't do for NavigationToolbar.

This is failing all the tests. Probably not going to get merged until that's fixed! Looks like you need to updatematplotlibrc.template?

@DietmarSchwertberger that QT specific tool is one of the reasons this toolmanager exists, and MEP27 is been a work in progress for a long time.
We don't want to have or at least reduce the number of "backend specific" tools, but that is a big discussion for another day.

Is there a plan to make ToolManager the default? 3.1?

Yes.

I don't think that we should wait for the testing as this would slow down ToolManager development quite a lot.

I'm not bent against that, I just don't have the bandwidth to do a proper review right now, and tests would have helped.

@anntzer I agree that we need to test this, but I agree with@DietmarSchwertberger about not holding this PRs because of that.
Is there any other volunteer to review this PRs?

@jklymak fixed, "all checks have passed"

@anntzer@timhoffm can we look at this now?

I would drop shift-ctrl-c as a default shortcut -- it is only useful in context where ctrl-c is not available (because that's an interrupt), not where ctrl-c is already a shortcut for copy.

@anntzer it was@efiring that suggested shift+ctrl+c in#1987 (comment) do we keep it?

But he suggested itinstead of ctrl-c, not in addition. I would not keep both.

@timhoffm is it OK if@jklymak merge this?

A week is fine ;-)

Right now does the copy always give you a png? Would be great to support vector formats like svg as well.

I manage to do this with Qt backend on windows, with something like this:

import iofrom PySide.QtGui import QApplication, QImagefrom matplotlib import pyplot as plt# do a matplotlib plot# this saves the plot as svg to clipboardbuf = io.BytesIO()fig.savefig(buf, format='svg')data = QtCore.QMimeData()data.setData('image/svg+xml', buf.getvalue())QApplication.clipboard().setMimeData(data)

Then I can go to word to paste it as an svg image.
But somehow this doesn't work on macOS, I haven't figured out why.

Does copy work with PyQT5 on Mac? I am unable to get anything onto the clipboard with cmd-c.

@jdtsmith are you using the toolmanager? it was tested long time ago, I don't have mac to test. If it's not working lets report a bug

I figured that out thanks; copy and scroll to zoom both work for me on Mac with this:

importwarnings,matplotlib.pyplotaspltplt.ion()withwarnings.catch_warnings():warnings.simplefilter("ignore")plt.rcParams['toolbar']='toolmanager'# scrollzoom + Cmd-C copy!

Maybetoolmanager should be the default!

Maybetoolmanager should be the default!

Yes I agree, we need to properly pan and execute the transition

Did the situation for tk change?

Maybe add a comment in the starting post that tk is not working currently.