Skip to content

Conversation

@thegecko
Copy link
Contributor

@thegecko thegecko commented May 11, 2024

As discussed in #200880 we are keen to ensure there are contribution points in all debug window context menus

This proposal implements contribution points for the watch, breakpoints and disassembly views.

To use this proposal, the package.json would look similar to:

{
        ...
	"enabledApiProposals": [
		"debugContext"
	],
	"contributes": {
		"commands": [
			{
				"command": "proposed.dummyMenu",
				"title": "Dummy Menu"
			}
		],
		"menus": {
			"debug/disassembly/context": [
				{
					"command": "proposed.dummyMenu"
				}
			],
			"debug/watch/context": [
				{
					"command": "proposed.dummyMenu"
				}
			],
			"debug/breakpoints/context": [
				{
					"command": "proposed.dummyMenu"
				}
			]
		}
	},
        ...

An example can be found here: https://github.com/thegecko/vscode-proposed-debug

Fixes: #200880, #150161

Relates with: #212500

const context = delegate.getActionsContext ? delegate.getActionsContext(event) : undefined;
// Determine whether the action source is contributed via a proxy (e.g. from an external extension)
// Context will need to be serializable (e.g. no recursive structures)
const contributedAction = (actionToRun instanceof MenuItemAction) && actionToRun?.item?.source;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to the existing context menus already utilising referenced objects in their commands which cannot be serialised (e.g. due to circular references or bigint types), a mechanism is required to determine if the context menu item has been contributed by an external extension.

The method chosen here relies on a source existing for external contributions. I'm not a bug fan of this, is there a better way?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't try to use two different contexts for one toolbar. That is one thing that has always been an issue with exposing menus to extensions, and I'm not sure whether there's a better way to handle it, I will try to discuss that this week.


return {
sessionId: this.debugService.getViewModel().focusedSession?.getId(),
expressionId: expression.getId(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this ID is meaningful or exposed to extensions elsewhere, or is it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could be right, but it may be useful as a unique ID?

@thegecko
Copy link
Contributor Author

I assume this went stale @roblourens

@thegecko
Copy link
Contributor Author

@roblourens Now we have #212500 merged, I'm keen to revisit contribution points for the debug context menus in this PR.

I'm happy to rebase it, but want to confirm this is the correct approach first. TY.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Debug viewContainer menu contribution points

2 participants