Conflict with Copy/Paste shortcuts

[paxswill]

When I'm trying to add an API key to Pyfa, I copy the info from CCP's Api key site, but I'm unable to use ⌘V (command-V) to paste in the key ID or vCode as that is in use by the "From Clipboard" command. Could those commands either have their shortcuts disabled while the API editing window is focused (probably hacky and leaves other corner cases unsolved) or possibly change the "To Clipboard" and "From Clipboard" to ⇧⌘V/⇧⌘C (shift-command-V/C). I am still able to right-click the text field and paste from there, so adding help text to tell people to do that might be a quick fix as well.

[blitzmann]

Are you using the basic -mac version or the -mac-wx3 version, and what is your OSX version? This is the first I'm hearing of the shortcut completely being overridden rather than the intended added functionality. I'll have to look into this more

[paxswill]

-mac-wx3, 10.10.5

[resinneublem]

Yeah I can reproduce too. Will do some googling to see about a work around.

[resinneublem]

As a short term work around you can right click and choose "Paste" on the text field.

There may be a way to disable the menu items but I don't know you'd be able to deterministically tell when to disable/enable.

[RealSalmon]

This is also an issue with the -mac version in v1.18.0 (OS X 10.10.5)

[blitzmann]

I still have not had a change to check, but this may be related to the fix for the menu as stated here: #456 (comment)

[blitzmann]

I can finally confirm that I can reproduce this in current release. With the current master it works, but probably due to a recent switch from Frame to Dialog that may or may not be sticking around. Anyway, this issue here is event propagation - need to find a way to stop paste events from being handled by the main window if they are happening in a text ctrl.

[resinneublem]

I did some digging into this, and it looks like the problem is 0a10f2d

Specifically the override

Pyfa/gui/mainMenuBar.py

Lines 54 to 56 in 3396056

	if 'wxMac' in wx.PlatformInfo and wx.VERSION >= (3,0):
	wx.ID_COPY = wx.NewId()
	wx.ID_PASTE = wx.NewId()

If I comment that out, copy/paste works just fine. When you're using a text control, it behaves as normal (even though the Edit menu highlights). And when you're not in a text control, it will import/export the fit.

I re-read #456 and I'm not 100% sure why that commit should fix that problem. I'm running wxpython 3.0.2.0 installed from homebrew.

For what it's worth, I did some research and it looks like this has been a common problem. So I think wxWidgets is doing some hacking under the covers to allow the focused text control to accept the key command instead of letting the accelerator take it:

• http://trac.wxwidgets.org/ticket/11320
• http://trac.wxwidgets.org/ticket/14953

---

So one simple solution is to rip out

Pyfa/gui/mainMenuBar.py

Lines 54 to 56 in 3396056

	if 'wxMac' in wx.PlatformInfo and wx.VERSION >= (3,0):
	wx.ID_COPY = wx.NewId()
	wx.ID_PASTE = wx.NewId()

but I can't reproduce #456 - perhaps the 2nd half of 0a10f2d#diff-bd60c14d60292b0c9010baa9dbaf4bc8R84 fixes it. (The part that dropped the if 'wxMSW' in wx.PlatformInfo else "" bits)

[blitzmann]

So glad you're looking into this. If you can, please submit a PR and I will test both 2.8 and 3.0.2.0 for OS X (unless you want to attempt to build it yourself :P)

[resinneublem]

@blitzmann how do you go about testing 2.8? Is that something that I can use virtualenv for?

[blitzmann]

how do you go about testing 2.8? Is that something that I can use virtualenv for?

ehh... I mean, you can install 2.8 and 3.0 side by side, however on OS X it's pretty janky IIRC. virtualenv may be of limited help (whoeevr, it would only handle the wxPython side, no wxWidget binaries), but I'm not knowledgeable enough about virtualenv to be of any use.

My thought for testing in 2.8 would be to use the dist.py script to create the mac-deprecated build (which is 2.8)

[DarkFenX]

Is it still actual?

[DarkFenX]

I removed offending bits (assigning custom IDs to copy-paste) and tested tested scenarios listed in #915. Had no issues on my Mac with both source build and binary build built by travis. So let's consider this as fixed, hopefully it doesn't cause any issues on Macs.