http://trac.wxwidgets.org/ticket/15678 http://trac.wxwidgets.org/ticket/14953
They are not going to fix it, and the behavior is considered correct. The developer should not use the default names for various buttons that overlap with system shortcuts and manually name them without the & if they conflict. That's the consensus on the wx trac anyway. I submitted a patch that did exactly this, had KiCad manually set the button names if being built for OS X (which was quite a number of buttons), but it was suggested that we patch wx instead. It's one or the other. This bug is very annoying. Could we please settle on a course of action? It isn't considered a bug by the wx developers so isn't going to be fixed, so the only options available are work arounds, unfortunately. -- "Violence is the last refuge of the incompetent." - Isaac Asimov > On May 5, 2016, at 4:36 AM, Simon Wells <[email protected]> wrote: > > the only issue i see with this patch is it seems to be working around > the problem rather than fixing it. Has this been fixed in wxwidgets > 3.1 if anyone knows? > > Simon > > On Thu, May 5, 2016 at 8:38 PM, Collin Anderson <[email protected]> > wrote: >> Another little OS X fix. Most, though not all, of the dialogs in KiCad that >> have cancel buttons break copy of text on OS X. If you highlight text (for >> example, the net of a pad, an operation I find myself doing fairly often) >> and hit 'Command-C', the dialog is closed and the text is not copied. >> Command-C is not ever used in this way under OS X, it should and is always >> intended to copy whatever is selected. >> >> The problem stems from how many of the dialogues in KiCad are declaring >> their cancel buttons. If one declares a button with this constructor: >> >> wxButton( this, wxID_CANCEL ) >> >> then the default name is filled in, which is "&Cancel". The & is what makes >> a button have a keyboard shortcut with the directly following letter (C) in >> windows, but wx translates this to command-<letter> on OS X. This means any >> button with the name "&C****> will break copy and paste on OS X and simply >> trigger the button event stead. >> >> I went through and fixed *every single button* in Kicad, such that the >> code/behavior is completely unchanged on other platforms, but if __APPLE__ >> is defined, it will explicitly name the button "Cancel" or "Close" as >> opposed to "&Cancel" or "&Close" (both the automatic fill-ins if not >> specified). It's not pretty, but the only other option I can see is remove >> the keyboard shortcut for the cancel and close buttons entirely, or at least >> change them to a different letter, but that could potentially break other >> people's workflows. >> >> Here's the patch! >> >> >> >> -- >> "Violence is the last refuge of the incompetent." - Isaac Asimov >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
