Thanks to visit codestin.com
Credit goes to github.com

Skip to content

implementation of the copy canvas tool #10446

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

Merged
merged 10 commits into from
Apr 26, 2018
Merged

Conversation

fariza
Copy link
Member

@fariza fariza commented Feb 13, 2018

PR Summary

Answering to #1987
This is the implementation of the CopyToClipboard tool

  • GTK3
  • tk
  • Qt
  • Wx
    Before it get's merged we need to have the three backends that are supported by the ToolManager

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@fariza
Copy link
Member Author

fariza commented Feb 13, 2018

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

@anntzer
Copy link
Contributor

anntzer commented Feb 13, 2018

@fariza
Copy link
Member Author

fariza commented Feb 14, 2018

@anntzer thanks for the tip, QT was pretty easy

The tk still pending... HELP!!!

@@ -1389,6 +1389,7 @@ def _validate_linestyle(ls):
'keymap.yscale': [['l'], validate_stringlist],
'keymap.xscale': [['k', 'L'], validate_stringlist],
'keymap.all_axes': [['a'], validate_stringlist],
'keymap.copy': [('ctrl+c', 'cmd+c', 'shift+ctrl+c'), validate_stringlist],
Copy link
Contributor

Choose a reason for hiding this comment

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

list instead of tuple? (as above, basically)

Copy link
Member Author

Choose a reason for hiding this comment

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

@anntzer Done

@fariza fariza changed the title WIP: GTK3 implementation of the copy canvas tool WIP: implementation of the copy canvas tool Feb 23, 2018
@fariza fariza changed the title WIP: implementation of the copy canvas tool implementation of the copy canvas tool Feb 26, 2018
@fariza
Copy link
Member Author

fariza commented Feb 26, 2018

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

Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

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

Since this code will only be triggered by a user action from a GUI, it‘s probably better to show the warning in a message box. A warning in the console may go unnoticed and the user may wonder why there is no image in the clipboard.

@fariza
Copy link
Member Author

fariza commented Mar 12, 2018

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

@DietmarSchwertberger
Copy link
Contributor

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

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

backend_tools.ToolRubberband = RubberbandQt
backend_tools.ToolCopyToClipboard = ToolCopyToClipboardQT

@fariza
Copy link
Member Author

fariza commented Mar 21, 2018

@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

@DietmarSchwertberger
Copy link
Contributor

@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.

@fariza
Copy link
Member Author

fariza commented Mar 21, 2018

@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

@DietmarSchwertberger
Copy link
Contributor

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

@anntzer
Copy link
Contributor

anntzer commented Mar 21, 2018

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

@fariza
Copy link
Member Author

fariza commented Mar 21, 2018

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

@fariza
Copy link
Member Author

fariza commented Apr 9, 2018

@anntzer @timhoffm Is something missing?

@anntzer
Copy link
Contributor

anntzer commented Apr 9, 2018

See #10851 (comment).

@DietmarSchwertberger
Copy link
Contributor

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 the NavigationToolbar2QT. 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.

@jklymak
Copy link
Member

jklymak commented Apr 12, 2018

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

@fariza
Copy link
Member Author

fariza commented Apr 12, 2018

@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.

@anntzer
Copy link
Contributor

anntzer commented Apr 12, 2018

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.

@fariza
Copy link
Member Author

fariza commented Apr 12, 2018

@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?

@fariza
Copy link
Member Author

fariza commented Apr 13, 2018

@jklymak fixed, "all checks have passed"

@fariza
Copy link
Member Author

fariza commented Apr 18, 2018

@anntzer @timhoffm can we look at this now?

@@ -971,11 +971,18 @@ def trigger(self, *args):
dialog.done = lambda num: dialog.frame.master.withdraw()


class ToolCopyToClipboardTk(backend_tools.ToolCopyToClipboardBase):
def trigger(self, *args, **kwargs):
Copy link
Contributor

@anntzer anntzer Apr 18, 2018

Choose a reason for hiding this comment

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

I would move this to the base class ("The current backend does not implement the copy tool.").

In fact this could even be moved to ToolBase...

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

def trigger(self, *args, **kwargs):
message = "Copy tool is not available for Tk backend"
self.toolmanager.message_event(message, self)
pass
Copy link
Contributor

Choose a reason for hiding this comment

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

... then you don't need this class anymore.

@anntzer
Copy link
Contributor

anntzer commented Apr 18, 2018

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.

@fariza
Copy link
Member Author

fariza commented Apr 18, 2018

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

@anntzer
Copy link
Contributor

anntzer commented Apr 18, 2018

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

@@ -1421,6 +1421,7 @@ def _validate_linestyle(ls):
'keymap.xscale': [['k', 'L'], validate_stringlist],
'keymap.all_axes': [['a'], validate_stringlist],
'keymap.help': [['f1'], validate_stringlist],
'keymap.copy': [('ctrl+c', 'cmd+c'), validate_stringlist],
Copy link
Contributor

Choose a reason for hiding this comment

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

list, not tuple

Copy link
Member Author

Choose a reason for hiding this comment

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

done

backend_tools.ToolSaveFigure = SaveFigureQt
backend_tools.ToolConfigureSubplots = ConfigureSubplotsQt
backend_tools.ToolSetCursor = SetCursorQt
backend_tools.ToolRubberband = RubberbandQt
backend_tools.ToolHelp = HelpQt
backend_tools.ToolCopyToClipboard = ToolCopyToClipboardQT
Copy link
Member

Choose a reason for hiding this comment

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

All the backend-specific tool classes do not have the "Tool" prefix. While, in general I would recommend to keep the prefix also in the backend specific classes, in the present situation I'm +0.3 not using it for consistency with the existing code. But I'm not familiar with that part of the code and don't know if there are any explicit policies on this. Maybe someone more experienced with that code can comment on this?

Same holds for the other backends.

Copy link
Member Author

Choose a reason for hiding this comment

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

@timhoffm you are right, we have to make the naming more consistent.
We can make a separate PR fixing all those names at once. I don't think it is relevant here

Copy link
Member

Choose a reason for hiding this comment

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

Do we consider the backend implementations private? If so we can clean up the naming soon and this PR goes in as is.

If not, we need a deprecation cycle. In that case, I‘d prefer to remove the Tool prefix in this PR as well and change everything later together.

Copy link
Member Author

Choose a reason for hiding this comment

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

As the initial warning states. Tool names might change. So I don't see a problem doing all of them in a single PR

Copy link
Member

@jklymak jklymak left a comment

Choose a reason for hiding this comment

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

I'll merge after giving @timhoffm a little bit if he still want the naming conventions fixed...

@fariza
Copy link
Member Author

fariza commented Apr 26, 2018

@timhoffm is it OK if @jklymak merge this?

@jklymak
Copy link
Member

jklymak commented Apr 26, 2018

A week is fine ;-)

@jklymak jklymak merged commit 17b6c30 into matplotlib:master Apr 26, 2018
@jklymak jklymak added this to the v3.0 milestone Apr 26, 2018
@alexysong
Copy link

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 io
from PySide.QtGui import QApplication, QImage
from matplotlib import pyplot as plt

# do a matplotlib plot

# this saves the plot as svg to clipboard
buf = 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.

@jdtsmith
Copy link

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

@fariza
Copy link
Member Author

fariza commented Jan 20, 2023

@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

@jdtsmith
Copy link

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

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

Maybe toolmanager should be the default!

@fariza
Copy link
Member Author

fariza commented Jan 20, 2023

Maybe toolmanager should be the default!

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

@frere-jacques
Copy link

Did the situation for tk change?

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants