IDLE's new right click menu doesn't seem to be working on Mac OS X. I am running OS X 10.8.3 with TK version 8.5.9 (which I think is what OS X 10.8.3 ships with). The right click activation I am trying is control-click.

It works OK as long as you are running Python from a framework build (--enable-framework). There are various OS X customizations in IDLE that are currently triggered by the runningAsOSXApp() function in idlelib/macosxSupport.py. One of the customizations is to add the event binding for <Control-Button-1> (in idle lib/EditorWindow.py). Restricting the customizations to framework builds is not useful nor correct and there are some other questionable customizations assumptions made in that module. I'll work up a patch. In the meantime, you can easily workaround it for testing by patching runningAsOSXApp to always return True.

The trigger for the customizations is probably too specific. The primary reason for a having a check that's more specific than 'if sys.platform == "darwin"' is to avoid using the customizations when someone uses an X11 build of Tk and I didn't know (and still don't) a way to check for a "native" Tk port.

Here's a patch that refactors many of the OS X customizations in IDLE based on more granular criteria, e.g. those that should apply to all Tk implementations vs those that depend on specific ones (Cocoa Tk, Carbon Tk, or X11 Tk) rather than the bogus current framework test. This should fix the specific problem of the control-click menu not appearing in non-framework builds along with various other issues such as missing menu items when using an X11 Tk on OS X. It does not address the issue of providing the OS X specific key set with a non-framework build: bpo-20580 addresses that.

(Just to be clear, the Tk situation on OS X has changed substantially since the original customizations were added by Ronald. So the checks weren't bogus initially. And I've modified some of them subsequently before understanding some of the "nuances" of the various Tk implementations.)

If there are no objections, I'd like to commit this cleanup soon. It should make things a bit easier for people testing IDLE from development builds on OS X and fix some long-standing bugs when linking with the Tk X11 variant on OS X.

If I understand the Bindings.py patch, the fragility changed from "If you edit menudefs, edit the Mac block that follows" to "If you change (e sections of) menudefs, edit macosxSupport.overrideRootMenu". That seems like a wash to me, except for the narrowing down of which sections might later be patched.

Every thing else that is not a change to macosSupport is guarded by macosSupport.xxx or 'darwin', so none from me.

New changeset f551740c26b6 by Ned Deily in branch '2.7':
Issue bpo-17654: Ensure IDLE menus are customized properly on OS X for
http://hg.python.org/cpython/rev/f551740c26b6

New changeset 67a7a49e7b78 by Ned Deily in branch '3.4':
Issue bpo-17654: Ensure IDLE menus are customized properly on OS X for
http://hg.python.org/cpython/rev/67a7a49e7b78

New changeset d8659dbebfd1 by Ned Deily in branch 'default':
Issue bpo-17654: merge from 3.4
http://hg.python.org/cpython/rev/d8659dbebfd1

Thanks for the review, Terry. The reasons for moving the menders changes are two. As noted in the comments, the menudefs were being customized early in IDLE initialization before calling Tk to create the root object and, therefore, we did not know at that point which kind of Tk we were running under. To properly customize, we need to know that, as we are now more careful to customize menus depending on the OS X Tk variant. Also, there already were other menu customizations being done in macosxSupport; now it is all in one place. It would be nice to reduce the fragility in the menu management. I would encourage anyone interested in working on IDLE to tackle it as a separate issue.

Applied for release in 3.5.0, 3.4.1, and 2.7.7.