Ned Deily added the comment:

I think that those two requirements, i.e. (1) a set of key bindings compatible 
with standard Cocoa text key bindings and (2) a set of key bindings kept in 
sync across all IDLE platforms, would be desirable but probably unattainable.  
A good next step would be for someone to make a table of the IDLE key bindings 
across the various keysets and platforms.  That would make it easier to make 
informed design decisions.

The "Classic Unix" keyset is quite different, with emacs-like multiple key 
strokes (like Ctrl-X Ctrl-N for New Window).  I wonder how widely it is used. 
For OS X, we have the aforementioned conflicts with system accelerators and 
with the Cocoa Tk we have already had to disable some common accelerators (like 
Cmd-M for Open Module..) because of conflicts with Cocoa Tk's builtin 
accelerators and the as-yet-unresolved Ctrl-5 and Ctrl-6 crashes (Issue16023).  
The X11 situation is a mess with Option and Command being reversed and, yes, 
there are still users of Python with X11 Tk on OS X (for one, MacPorts provides 
it as the default option).  Perhaps the best solution for it is a separate OS X 
X11 keyset.

Re function keys: I created a new user account on a current OS X 10.8 (with a 
US keyboard on a MacBook Pro).  It seems that function keys are enabled by 
default.  This is controlled by a checkbox setting in the Keyboard panel of 
System Preferences.  With the box checked (the default), you have to press the 
fn modifier key to enable the hardware control functions.  Inspecting the 
default set of Keyboard Shortcuts in the panel, the only F(n) keys defined are 
F11, F12, Cmd-F5, Opt-Cmd-F5, and Ctrl-F1 through Ctrl-F7.  This conforms to 
the current OS X Human Interface Guidelines, Appendix A Keyboard Shortcuts, 
with the addition that the entire range F8 through F12 are marked as Apple 
reserved.  (Interestingly, the guidelines do not note that Ctrl-Left and 
Ctrl-Right are now used by Mission Control by default.)

That said, it would be great if IDLE could more closely follow the OS X Human 
Interface Guidelines, including the accessibility guidelines for Universal 
Access.  Of course, IDLE is very much dependent on Tk in these matters.  So 
trying to improve things will require a fair amount of research and 
experimentation with the Apple docs, Tk code, and IDLE itself.  It would be a 
good project for someone interested in practical User Experience design.

Additional references:

https://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/KeyboardShortcuts/KeyboardShortcuts.html

https://developer.apple.com/library/mac/#documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXIntro/OSXAXintro.html

http://www.hcs.harvard.edu/~jrus/Site/System%20Bindings.html

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18444>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to