kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

is this settable in wxformbuilder as _base.cpp/h is autogenerated and
can't be changed manually

On Wed, Jul 13, 2016 at 11:32 AM, Brano Panak <bpanak@xxxxxxxxx> wrote:
> i tried solution from wx forum, modified just for test
> pcbnew/dimensions/grid file:
>
> dialog_set_grid_base.cpp
>
> m_sdbSizer1Cancel = new wxButton( this, wxID_CANCEL );
> with
>
> m_sdbSizer1Cancel = new wxButton( this, wxID_CANCEL , _T("Cancel"));
> and look this works as supposed in my setup.
>
> could you test in on different platforms and if this is ok, i can apply it
> elsewhere.
>
> regards
>
> Brano
>
>
>
> On 22/06/16 16:59, Wayne Stambaugh wrote:
>>
>> On 6/22/2016 10:33 AM, Collin Anderson wrote:
>>>
>>> I just discovered that OS X does in fact have similar behavior for
>>> buttons.  In most dialog windows, hitting command and the first letter of
>>> the text will 'click' the button, but this only works when the letter
>>> doesn't conflict with other shortcuts (like command-c or command-v for
>>> example).
>>>
>>> To get around that, it just remaps close/cancel to command-period
>>> (command-.) instead of command-C.
>>>
>>> Something weird is going on with how wxWidgets handles this.  I think the
>>> above behavior is done deep in the Cocoa API or something, and is not
>>> something any program needs to specifically implement.  I say this because
>>> certain windows in KiCad actually have this correct behavior, even the first
>>> letter activating the button.
>>>
>>> More troubling though is I just noticed that in windows where this
>>> behavior is not working, other things are broken too.  In OS X, you can use
>>> tab and the arrow keys to highlight widgets like buttons, text fields,
>>> whatever.  Additional capabilities can be enabled in the accessibility
>>> section of system preferences, and for many vision or motor impaired users,
>>> this ability to highlight widgets is vital to them being able to use
>>> software.  For example, you can have text-to-speech enabled such that it
>>> will read the text of a button currently highlighted.
>>>
>>> Anyway, this functionality is completely absent in any window where
>>> button shortcut behavior is also broken.  It is actually impossible to high
>>> light or operate the GUI without a mouse in these windows.
>>>
>>> HOWEVER, all of that works flawlessly in the windows with the shortcuts
>>> working.
>>>
>>> This seems completely separate from the command-c closing issue, and
>>> adding or removing the "&" to the button string does not influence it.  I
>>> think its probably something to do with the window type.
>>>
>>> Examples of windows with correct behavior:
>>>
>>>         Preferences in pcbnew
>>>         Most of the dimension dialogs in pcbnew
>>>         Color selection window for layers (you can also hit command-A and
>>> it will click apply)
>>>
>>> Non-working windows:
>>>         Preferences in eeschema
>>>         most more complex windows (component library editor, paths
>>> editor, netlist import/export, etc).
>>
>> I looked at some of the dialogs you've listed and they are all are
>> derived from DIALOG_SHIM so it's not that.  It may be worth looking at
>> each dialog to see what events we are intercepting and whether or not
>> that is the issue.  The fact that some dialogs work properly and others
>> do not makes me think that it could be an issue with our dialog design
>> rather than an issue with wxWidgets.
>>
>>>
>>>
>>>
>>> I suppose the 'proper' solution would be to disable wx's direct handling
>>> of button shortcuts for OS X, while figuring out whatever it is that is
>>> letting OS X perform native behavior in some windows or not others.
>>>
>>>
>>> Sorry, this is all just observational stuff, I can't really be of much
>>> help until or if I get a better handle on wx.
>>>
>>> That said, as an OS X user, I didn't even notice any of this until today,
>>> and I've been using KiCad for a year+ now.  So its hardly mission critical.
>>> I also doubt there is anyone who is vision or motor impaired who is doing
>>> EDA tasks with KiCad.
>>>
>>> Still odd though.
>>>
>> It may not be that odd.  Some of this is due to wxGrid (and I suspect
>> wxListCtlr and wxListView) behavior.  wxGrid intercepts the usual return
>> key behavior when you are editing a grid cell so the default button (OK)
>> never receives the return key.  This isn't that unusual.  I've tested
>> other non-wxWidgets applications with grids in dialog boxes and the
>> behavior is similar.
>>
>> _______________________________________________
>> 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