Tk Source Code

(1) The Wish binary has an "Edit" menu with entries for "Undo" and "Redo".  The "Redo" menu entry has a keyboard shortcut "Command-Y".  This should be replaced with the Apple standard shortcut adopted in Tk/Aqua 8.6, "Command-Shift-Z".

(2) The menu entries for Undo, Redo appear to do something in addition to the bindings and events defined in tk.tcl.

The keystroke "Lock-Command-Y" causes a <<Redo>> in a text widget, although it is not listed in [event info <<Redo>>], nor is it bound to a command in any of the widget's binding tags.

The keystroke "Lock-Command-Z" causes a double <<Undo>>.

If "Caps Lock" is not active, the widget behaves as expected.

It appears that, when "Caps Lock" is active, the operations defined in the application menu are performed IN ADDITION TO any operations defined by Tk events and bindings.

I wonder if this isn't really a DUP of [3607200]: If the Shift/Lock atributes
are handled inconsistant in Aqua, then how can we be sure that
the bindings itself work as expected in combination with Shift/Lock.

In my view, [3607200] MUST be fixed first before even attempting
to fix this one. As long as [3607200] is "Wont Fix", this one should be as well.

allow_comments - 1

After giving this further consideration, I'm disinclined to take any action. Even after acknowledging the behavior, I'm not sold on the suggestion that this is a substantive problem which requires fixing. "Doesn't conform to the HIG" isn't a sufficient reason IMO. And, as we've discussed, any production app is going to replace the stub menu with its own menu anyway. And I actually don't want to remove the stub edit menu, even if it has some inconsistent behavior.

The reported bug occurs when launching wish from the command line.

There is a similar problem with the <<Paste>> menu entry - when "Caps Lock" is active, <Command-v> generates a double <<Paste>> event.

I've just tried launching wish from a Wish.app bundle (ActiveState 8.6.0), which also launches a console, and this has different but still incorrect behavior for the wish top-level (the console toplevel behaves correctly).

When the wish toplevel has focus, <<Undo>> works as expected, but neither <Command-Shift-z> nor <Command-y> generates a <<Redo>>.  Also, <Command-c> generates a <<Copy>>, but <Command-v> does not generate a <<Paste>>.  This seems to be independent of whether "Caps Lock" is active.

It is true that in an application, the developer would provide an application-specific menu.  However, it is helpful if Wish.app (and also command-line-launched wish) behave in the documented way.  If removing the edit menu would solve the problem, I agree that it should be removed - as you say it is only intended as a placeholder.

I've taken more time to look at this. Reviewing the Tk source code and the items documented here, I can confirm most of the reported behavior. As noted, the "edit" menu items in the stub menu are defined at the Cocoa level, not at Tk's level, and they are just there because Apple's HIG calls for some sort of menu. I see little benefit to wrangling with these Cocoa-level events to bring them in line with events at the Tk level; that menu is not intended to be used in production apps. What is the use case for retaining the "edit" menu as-is instead of implementing an application-specific one, with proper Tk behavior? If the edit menu is such a source of confusion and conflict (and I'm not persuaded that it is, despite the inconsistencies documented here), would it not make more sense to remove it altogether? (I'm not advocating such a solution, because I'm not fully persuaded these are major issues, but it would resolve the reported behaviors.)

OK...I'l take a closer look, thanks.

How about:
    <http://core.tcl.tk/tk/ci/ceea1367f2?sbs=1>
Does that help?

Isn't that configurable here?
    <http://core.tcl.tk/tk/artifact/47dc4f99fc?ln=86-87>
I don't know how to specify "Command-Shift-Z" here, apart
from that it looks easy to be changed.

The base menu bundled with Wish is a Cocoa stub menu that is intended to be overridden with an app-specific menu. Those default menu entries are Cocoa-based and are not directly configurable from Tk--the fact that such command as "copy," "paste," etc. work is because the Cocoa menu provides that functionality. This is why you see some overlap and redundancy in the events firing. I will see if there is anything that can be done here, but I suspect there may not be.