Per-window commands

[mhsmith]

What is the problem or limitation you are having?

If you want different menus for different windows, you currently need to detect when the active window changes and alter App.commands manually. This most obviously affects DocumentApp, where you might want to enable or disable commands depending on what the user has selected.

But it may also affect other multi-window apps which don't involve "documents" per se. For example:

• In Chrome, the Tab menu contains a list of tabs for the current window only.
• An app to control a robot might provide separate windows for different components of the robot, with content showing information about the component, and different menus for different component types.

Describe the solution you'd like

Add a Window.commands property, which would work as follows:

• On macOS, the app menu would be a union of the commands from the App and the currently-active Window.
• On GTK and WinForms, each window’s menu would be a union of the commands from the App and that window.

Since each window has its own toolbar, this implies that toolbar commands should be automatically added to Window.commands, rather than App.commands at present.

[freakboy3742]

Generally agreed. The biggest issue/risk I see is around instance identity, and the coalescing process of window commands. If I have 2 windows, both of which have a "foobar" command, is that 2 instances of Command, or the same command added to 2 different windows?

I'm also uncertain about one detail on Cocoa's coalescing of menus: would menu items for window A would be visible when Window B has focus (and if they are visible, are they enabled)? Discoverability would suggest they should be visible but disabled; but that could easily lead to overwhelming menus if A and B have disparate sets of commands. I guess we could add a property to Group that flags the group as being "window specific"...

FWIW - I've been tinkering with #1870 and #97 in my spare time, and I've got a similar need there - it turns out to be easiest to flag a group as being a "system tray" group, which takes the group out of the normal menubar flow. There might be an analog here with Window-specific groups; although it might require registering groups with the window in addition to commands.

[mhsmith]

Just saving this suggestion from #2244 (comment):

Window.commands would default to an empty CommandSet, but if you want to hide the menu bar, you can set it to None. On macOS, there would be no visible difference between an empty CommandSet and None.

[mhsmith]

I'm also uncertain about one detail on Cocoa's coalescing of menus: would menu items for window A would be visible when Window B has focus (and if they are visible, are they enabled)? Discoverability would suggest they should be visible but disabled; but that could easily lead to overwhelming menus if A and B have disparate sets of commands.

I think hiding them is the only reasonable solution:

• Discoverability isn't helped by showing them disabled, because there would be no indication of how to enable them.
• The fact that you added the command at the WIndow level means it relates somehow to the content of that window. So it doesn't make sense for the command to be visible when the window might be obscured. If you want a command to always be visible, you can always add it at the App level.
• In a multi-window app, different windows are likely to have the same set of window-specific commands (e.g. Save), so only one of them could be displayed at a time anyway.