kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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 <metacollin@xxxxxxxxxxxx> 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 <swel024@xxxxxxxxx> 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 <metacollin@xxxxxxxxxxxx> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>