kicad-developers team mailing list archive

[Collin Anderson <metacollin@xxxxxxxxxxxx>]

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 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.

-- 
"Violence is the last refuge of the incompetent." - Isaac Asimov

> On Jun 22, 2016, at 6:59 AM, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx> wrote:
> 
> On 22.06.2016 14:44, Collin Anderson wrote:
>> I have been using a version of wx patched with my hacky patch for
>> about a month or so, and haven't run into any issues.  So I think the
>> mechanism (removing the & in the start of the button string) is pretty
>> safe.
> 
> I looked around a bit in GUI guidelines and other OS X applications back then and it seems that OS X never uses such hot-keys/shortcuts for buttons (or whatever it is called).
> I wanted to check if it is possible somewhere in a common button class to just filter out "&" completely... to avoid that any user defined button defines maybe other problematic shortcuts.
> Unfortuantely, not much time lately to spend on this.
> 
> 
> Regards,
> Bernhard