Cmd-C is interpreted as "Close" in dialogs on OS X

[Warren Young]

In at least two different dialogs, I have accidentally closed the dialog with Cmd-C when attempting to copy text.

There is no reason to have this key binding on OS X. Escape is the standard key for canceling a dialog.

[Blair Bonnett (bcb)]

Not a Mac user so I can't confirm this myself, but can you add a couple more details? Does this happen in all programs (Eeschema, PcbNew etc) or just one? All dialogs, or just some of them (and if so, can you remember which ones)? Also, can you add your version and build details (which you can get from Help -> Copy Version Information). Thanks!

[Warren Young (tangentsoft)]

> Does this happen in all programs

I have found examples of this in:

* EEschema (Choose Component, Set Active Libraries, Page Settings)

* Part editor (Component Properties, Select Library)

* PCBnew (Library Tables, Dimensions > Grid, Layers Setup)

* Footprint Editor (Pad Settings)

* PCB calculator (Add Regulator)

* CVpcb (Edit Equ Files List)

I didn't find any dialogs in gerbview that show this problem, but as far as I could find out, gerbview doesn't really have any dialogs other than "list D codes," which is more of a message box. If you know of a true dialog, especially one with a text input field where Cmd-C might be useful, let me know and I'll test it.

I don't see any dialogs at all in PI Editor or the bmp2component tool.

> All dialogs

Are you asking me to test every dialog in every program in the KiCad suite?

If you are just asking if there are counterexamples, then yes: Netlist in both EEschema and PCBnew, the design rules editor in PCBnew, and Load Footprint in the footprint editor.

> version and build details

Application: kicad
Version: (after 2015-jan-16 BZR unknown)-product Release build
wxWidgets: Version 3.0.2 (debug,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8)
Platform: Mac OS X (Darwin 14.1.0 x86_64), 64 bit, Little endian, wxMac
Boost version: 1.57.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=ON
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON
         KICAD_USE_WEBKIT=ON

It was built from this source: https://github.com/metacollin/homebrew-kicad

[Blair Bonnett (bcb)]

Thanks for adding that information.

> Are you asking me to test every dialog in every program in the
> KiCad suite? If you are just asking if there are counterexamples,
> then yes

Yeah, I was wondering if there were counterexamples. I should have been clearer with the question -- glad you didn't try all dialogs!

This appears to be a OSX bug in wxWidgets: http://trac.wxwidgets.org/ticket/15678 -- if there is a button with wxID_CANCEL, it gets triggered by Cmd-C and closes the dialog.

Having said that, the design rules editor in PcbNew does seem to have such a button but doesn't respond to Cmd-C on your system. I wonder if the Cmd-C event is prevented by something else on the dialog?

Anyway, as a non-OSX person this is all just speculation on my part. I might ping the OSX developers on the mailing list and see if they can see any reason for this behaviour, and if there is any workaround we can apply until wxWidgets is fixed.

[fluffyfrog (frotteefrosch)]

I would be delighted if somebody could fix this. It can be very annoying.

[Diogo (diogocondeco)]

Actually in mac os x the correct/default behaviour should be:

CMD-C copy
CMD-W close the window (the actual behaviour of CMD-C right now).

I think the default should be the way to go... so I would also appreciate this improvement. Thanks

[Diogo (diogocondeco)]

It seems to me the CMD+C behaviour to close the dialogs (yes not windows!!) is only present on dialogs with a cancel button. This tells me that probably the shortcut is a binding for that operation/button.

[Adam Wolf (adamwolf)]

This is still happening today.

[Adam Wolf (adamwolf)]

Here is the upstream bug: http://trac.wxwidgets.org/ticket/15678

[Maciej Suminski (orsonmmz)]

I see there is DIALOG_SHIM::FixOSXCancelButtonIssue() used in a few dialogs, supposedly fixing the problem. Would any OSX user comment if the bug can be closed or if there are still places where it does not work? Thank you in advance.

[Diogo (diogocondeco)]

It seems to be working just fine. I would suggest to close this one as fixed, since most (if not all) dialogs are fixed. If there is any not fixed yet, it can always be reported separately.

BTW thanks to whoever fixed this!