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
