Allow a custom label for menu items, overriding the command name

[JasonWeill]

Problem

Found while working on a fix for https://github.com/jupyter/notebook/issues/6806.

When I create a menu item based on a command, the command's label is the only possible label for the menu item:

https://github.com/jupyterlab/lumino/blob/f3ca270d7c1173cc52a8715d1fe7c4e1ea3ab2a5/packages/widgets/src/menu.ts#L1770

I would like to override this label to, for example, use a shorter one for a compact menu.

Proposed Solution

Add an optional property called label to Menu.IItemOptions. If present, the label in IItemOptions takes precedence over the label for the command.

[krassowski]

Thank you for opening this. It looks like a reasonable additive change, I do not see any downsides.

I would like to override this label to, for example, use a shorter one for a compact menu.

This is currently accomplished by functional labels, e.g. for command palette we use longer label by checking for args['isPalette'] as in the terminal:create-new command. There are two problems with this solution:

• command has to know about its uses
• we do not receive isSomething from most emitters. Once we rework commands to allow them to receive the event that triggered them it would no longer be a problem as potentially it could enable something like:

  {
  label: (args) => (
    args.event & findMenuForEvent(args.event).?id == 'myCompactMenu'
      ? 'shortLabel'
      : 'longLabel'
  )
  }

The first problem is a design question - should menus be:

• a) simple with commands being omniscient, or
• b) allowed to take responsibility for labels, reducing the responsibilities of commands.

(b) would imply small changes to where localisation of label would need to happen (in package with command or package with menu, only of practical significance when reusing command in third-party package), but I think it is reasonable.

[fcollonval]

Some thoughts, if we want to improve application performance, we should move towards having a no-code description of entry points such as commands in menus or toolbars. This means that we indeed have two paths for customization, allow the command consumer (i.e. menus or toolbars) to override the default command attribute (low code approach) or we go with a code approach like the one suggested by Mike above. But this definitely converge to design questions raised above (and not only for menus):

• Omniscient commands
• Customization by consumer

The second one is easier and more customizable (you may not have the power to customize the label of command from an external source). The first one ease code understanding by having a single source of truth.

From my experience with the introduction of customization through settings in core and extension, I lean towards the second approach (customization by consumer).