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
