Custom menu entires, context menu entries, and action bar items

[jandrieu]

I'd like to add a context menu item that performs a Google search using the current selection.

However, there doesn't seem to be a way to bind to the right click or to an open context menu event.

I see several requests for features to add to the context menu... wouldn't it be easier if VS Code just made it possible for extensions to register a context menu entry?

[Thaina]

+1

[twomarktwo]

+1

[nevadascout]

+1

[f111fei]

+10086

[jrieken]

Should be similar to how command palette contributions work. Tho in addition to the label -> command_id mapping it needs (1) a condition when to show, like glob-pattern to the active editor, and (2) a path-like structure where to show

[f111fei]

@jrieken And we need more info that the context. Example:
Right Click on Explorer View, The context contains viewer and element, See
https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/parts/files/browser/fileActions.contribution.ts#L40

How to let the developers know the context. And sometimes the context can`t be serialized

[Thaina]

@f111fei Still should be the same flow for pattern matching. Also it should be able to make condition menu from current focused area. Menu could be shown or hidden from selected text so, yeah, I think it could be the same

[jrieken]

Some sample from what we have with PR #7704

1. Add an icon to the editor action bar

{
    "command": "v.sayHello",
    "title": "Hello World",
    "icon": "./media/Preview.svg",
    "context": {
        "where": "editor/primary",
        "when": "typescript"
    }
}

1. Add an action with theme-aware icon that shows for all typescript files and files that match **/*.svg as primary action and as secondary action for txt files.

{
    "command": "v.sayHello",
    "title": "Paul Bier",
    "icon": {
        "light": "./media/Preview.svg",
        "dark": "./media/Preview_inverse.svg"
    },
    "context": [{
        "where": "editor/primary",
        "when": [
            "typescript",
            {"pattern": "**/*.svg"}
        ]
    }, {
        "where": "editor/secondary",
        "when": {"pattern": "**/*.txt"}
    }]
}

1. Add an action for json-files to explorer context menu

{
    "command": "v.sayHello",
    "title": "Open With Hex",
    "context": {
        "where": "explorer/context",
        "when": "json"
    }
}

Plan is to start with these locations (values for where-property): editor/primary, editor/secondary, editor/context, and explorer/context. The when-clause is a DocumentSelector and applied to the resource in context - that is a file from the explorer or the resource showing in an editor etc.

Also, the resource in question will be passed to the command as argument.

[bpasero]

@jrieken should we maybe enforce to provide 2 icons for light and dark themes so that we do not end up with extensions that look bad in one theme?

[bpasero]

Also, I see for the explorer you call it explorer/context but maybe we need to be more specific: there is the top level action bar with primary and secondary actions and there is the tree item specific action bar also with primary actions (they appear at the end of the item) and secondary actions that show up in the context menu.

[jrieken]

@bpasero I see the point with two icons but effectively we cannot make sure those icons look good or aren't the same. I think with a simple path you get to going quickly and then make theme changes - it's also what we do for editor decorations.

Wrt the explorer I understand we have four places: explorer/primary, explorer/secondary, and primary & secondary for context items. For now, I am planning to start with secondary action for items. I wonder if we should stick with explorer/context (which aligns nicely with editor/context) and in the future have explorer/context/primary for the primary actions on items?

[bpasero]

@bpasero I see the point with two icons but effectively we cannot make sure those icons look good or aren't the same. I think with a simple path you get to going quickly and then make theme changes - it's also what we do for editor decorations.

Ok, if we have a similar API model elsewhere already, +1 for keeping it the same.

Wrt the explorer I understand we have four places: explorer/primary, explorer/secondary, and primary & secondary for context items. For now, I am planning to start with secondary action for items. I wonder if we should stick with explorer/context (which aligns nicely with editor/context) and in the future have explorer/context/primary for the primary actions on items?

+1 for starting with something small and opening the API later for other use cases. The only thing I worry is that we now introduce a path (e.g. explorer/context) that we later need to deprecate because we found out it is not specific enough. If I think about all the places where one could want to contribute actions to, I end up with quite a list:

• every view, panel and editor-part has a top level action bar with primary and secondary actions
• every view, panel or editor-part can have 1-N controls inside with either
  • a control that just shows a context menu (e.g. the editor)
  • a viewer that accepts primary and secondary actions (e.g. problems view)
  • a split-view control that has its own primary and secondary actions (e.g. breakpoints view)
  • a viewer inside a split-view (e.g. "opened editors" in the explorer)

For contributing something to the explorer context menu, I think a path would look something like explorer/folder-view/secondary and to contribute to the "opened editors", something along the lines of explorer/editor-view/secondary.

Not saying we should support all of this in the beginning, maybe we only start with markdown for now which ends up to be a primary action for an editor.

[jrieken]

I see the point. I wonder if we can sell explorer/context as shorthand/alias for explorer/folder-view/secondary and if we loose something doing that? That would allow us to start simple and scale up on demand...

[bpasero]

Another thing I am wondering is how would you control the order of where the action should appear? E.g. would it be possible to even go further in the path we introduce to put the action into a specific group of the area (that is what Eclipse did, e.g. there was a group inside the context menu called "edit-actions" and you could point into there).

No I don't think we loose something if we have alias for the first area where we open up for contributions. We just have to document clearly where such a contribution ends up.

[jrieken]

I think we could just make that part of the path, like explorer/context/edit.

Yet another new thing that came up is how to handle things like right click, cmd+left click etc. Before, we could cmd+click the preview icon for Markdown to open the preview to the side. That isn't possible anymore. Similar to how keybindings have a key property, I believe we need to have a mouse property that goes like:

{
  "command": "foo.bar",
  "mouse": "cmd+left",
  "when": "markdown",
  "where": "editor/secondary"
}

The default for mouse would be left but can have values like cmd+right, right, etc

[bpasero]

I would probably try to simplify this to not talk about the key pressed while invoking the action but just the fact that a modifier is pressed.

Also note that someone might want to trigger an action using keyboard only and in that case we should also support the modifier even though it is not a click.

Finally, we currently cannot detect a modifier click if you click on an entry in the context menu.

[bpasero]

Another idea: we could just enrich the context that gets passed into the command with these infos (e.g. a modifier key was pressed when invoking the command). Instead of making this all declarative.

[jrieken]

there is some refining going on in #8059. We will differentiate between assigning UI attributes to a command (label, icons) and defining a menu. A sample:

"commands": [{
    "command": "v.sayHello",
    "title": "Paul Bier",
    "category": "Bier"
    "icon": {
        "light": "./media/Preview.svg",
        "dark": "./media/Preview_inverse.svg"
    }
}],
"menus": {
    "editor/title": [ { 
           "command": "v.sayHello",
           "when": "resourceLangId == javascript"
    } ]
}

First label, icons etc is assigned to the command v.sayHello. Such an assignment is allowed to appear multiple times but the last wins.

The menus structure has fixed properties (editor/title, explorer/context etc) for which an array of menu items can be defined. A menu item must refer to a command, can have when condition which works like the when in keybindings, and can have a alt command which is an alternative command (the editor action bar will swap in alt for default when pressing the alt-key and while hovering)

[Thaina]

Want to ask something. Is this feature would include extension for source control?

The Icon in sidebar only support git right now. Will this feature allow us to override it to use other source control as plugins?

[jrieken]

The Icon in sidebar only support git right now. Will this feature allow us to override it to use other source control as plugins?

No - this is about adding menubar entries in the editor title area, the explorer context menu, and the editor context menu for command either defined an extension or VS Code. We are consuming this API with the markdown extension: https://github.com/Microsoft/vscode/blob/master/extensions/markdown/package.json#L73

[Thaina]

OK, Thanks