This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: OS X IDLE keyboard accelerators fail or misbehave with Cocoa Tk
Type: Stage:
Components: IDLE Versions: Python 3.10
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: terry.reedy Nosy List: markroseman, ned.deily, terry.reedy
Priority: normal Keywords:

Created on 2014-02-10 10:10 by ned.deily, last changed 2022-04-11 14:57 by admin.

Messages (1)
msg210815 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2014-02-10 10:10
On OS X, most of the IDLE command keyboard accelerators that use the OS X <Option> modifier key do not work correctly with Cocoa Tk, the current native version of Tk 8.5 and 8.6 used on OS X 10.6 and later releases (and with the 64-/32-bit OS X binary installers from python.org).  These include the event bindings found in config-extensions.def:
    format-paragraph=<Option-Key-q>
    expand-word=<Option-Key-slash>
    zoom-height=<Option-Key-0>
    check-module=<Option-Key-x>
and in config-keys.def (IDLE Classic OSX set): 
    save-copy-of-window-as-file = <Option-Command-Key-s>

These all work (mostly) correctly with the older Carbon Tk, the original 32-bit-only native Tk for OS X, still shipped as Tk 8.4 in current systems (and still used with the 32-bit-only python.org binary installers), which was the Tk in use when native support for IDLE on OS X was originally implemented.

Modifier key support in Tk has long been problematic, with significant differences among platforms and even among the three implementations of Tk in use on OS X (besides the Cocoa and Carbon versions, there is an older OS X X11 version that differs in some respects from other Unix X11 versions).  Some of these differences have their origins lost in the mists of time or were due to no-longer relevant operating systems or hardware differences.  On the Tcl/Tk wiki, there is a page that attempts to document the differences based on empirical evidence (http://wiki.tcl.tk/28331).  Of particular relevance to IDLE is that the OS X Tk implementations do not use Alt binding modifiers since there was historically no Alt key on Mac keyboards.  In its place the Option key and binding modifier is used.  Likewise, the Command/Apple/⌘ key is used in place of the Windows key and is a binding modifier.  To that end, on OS X IDLE converts <Alt-> bindings and accelerators to <Opt-> ones, either during the build of IDLE or at run-time.  As noted above, that works pretty well for the older, now obsolete Carbon Tk.  However, it doesn't with the newer, current Cocoa Tk.  I believe this is primarily because Cocoa Tk supports the more sophisticated Cocoa text input system which maps most <Opt-> key combinations either directly to extended characters (like opt-s -> ß on US keyboard input methods) or as the first key of a two key composing sequence (e.g. opt-u a -> ä).  Cocoa Tk applications do not see these keys as separate events, only the final composed character.  Thus, the config-extension bindings above cause various characters to be input as text rather than triggering menu options.

The "save-copy-of-window-as-file" binding behaves somewhat differently: when typing Opt-Cmd-s, two instances of the Save File popup window appear with Cocoa Tk.  That erroneous behavior can be fixed by the straightforward change of the binding to <Control-Command-Key-s>.  Similar remapping to unused key bindings should be made for the extension bindings and documented accordingly so that all keyboard accelerators shown in IDLE menus are actually usable.

(For completeness sake, I'll note that the situation with OS X X11-based Tk in conjunction with the OS X XQuartz X server is much more bizarre.  Behavior differs depending on server preferences: either the roles of the Option and Command key modifiers are reversed or the Option modifier is not usable in Tk at all other than as an extended character set composing key.  The Tk wiki page documents much of this.  It isn't clear how a Tk application could accommodate all these different behaviors automatically so the current strategy of not trying to seems prudent.)
History
Date User Action Args
2022-04-11 14:57:58adminsetgithub: 64778
2020-06-08 00:38:35terry.reedysetversions: + Python 3.10, - Python 3.6, Python 3.7
2017-06-30 00:23:21terry.reedysetassignee: terry.reedy

nosy: + terry.reedy
versions: + Python 3.6, Python 3.7, - Python 2.7, Python 3.3, Python 3.4
2015-09-18 16:36:24markrosemansetnosy: + markroseman
2014-02-10 10:10:42ned.deilycreate