What's another wxWidgets patch at this point? If we want to give our OSX users the best possible experience then we probably should include the patch to fix this.
On 6/19/2016 6:05 PM, Chris Pavlina wrote: > Resurrecting this. Can we maybe consider adding another patch to wx into our > existing wx+OSX patch stack? It's really damned annoying. And of course wx > isn't going to fix it - yet another years-old ignored bug, they're clearly not > interested in fixing things like this. I regularly encouter bugs in their > tracker 6 years old or more, either completely ignored or falsely marked > fixed, > still active today... > > God I hate wx. > > On Thu, May 12, 2016 at 07:55:05AM +0200, Bernhard Stegmaier wrote: >> Why do you think they are not going to fix it? >> These two defects are still open and marked as “accepted defect”. >> They maybe won’t fix it like your patch does and yes, nobody knows when they >> will fix it. >> But it unfortunately is the same for many other OS X wxWidgets bugs… :( >> >> Until then, your patch looks quite fine for being used in KiCad on OS X. >> >> Moreover, as JP pointed out your first patch won’t work, because you changed >> generated code. >> Doing the same in the source .fpb files would mean to change it for every >> platform. >> That’s probably also not the way to go… >> >> >> Regards, >> Bernhard >> >> >>> On 12 May 2016, at 00:46, Collin Anderson <[email protected]> wrote: >>> >>> 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 >> >> >> _______________________________________________ >> 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 > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
