Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vscode built-in menus #4173

Merged
merged 9 commits into from
Jan 31, 2019
Merged

vscode built-in menus #4173

merged 9 commits into from
Jan 31, 2019

Conversation

akosyakov
Copy link
Member

@akosyakov akosyakov commented Jan 28, 2019

fix #4004
VS Code docs: https://code.visualstudio.com/api/references/contribution-points#contributes.menus

This PR alignes Theia menus with VS Code built-in menus:

  • navigator menu group is always sorted to the top
  • each menu command receives a current selected resource as first argument, Theia core URIs translated to VS Code URIs
  • supported menus:
    • explorer/context
    • editor/context
    • editor/title
    • debug/callstack/context
    • view/item/context

Out of scope, since there are not corresponding implementations in Theia:

Testing:
One can test against this VS Code extension: https://github.com/akosyakov/vscode-menus

There is no API breaking changes, but menu constants were renamed. Is it a case for major release? @marcdumais-work @svenefftinge

screen shot 2019-01-28 at 10 29 47

Location of built-in explorer groups in Theia and VS Code:
screen shot 2019-01-28 at 11 39 10

command: string;
title: string;
category?: string;
icon?: string | { light: string; dark: string; };
Copy link
Contributor

Choose a reason for hiding this comment

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

hello again: why here do we have icon light and icon dark ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

hello, my question is why it's not IconUrl that you introduced there

export type IconUrl = string | { light: string; dark: string; };

Copy link
Member Author

Choose a reason for hiding this comment

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

PluginPackageCommand is a format of raw command as it is defined by VS Code, with relative paths for icons. In order to download them, paths are converted into URLs served by hostedPlugin entry point. A new type is introduced to make it clear that a string is a url, not a raw path.

Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't be then URI instead of string for iconUrl ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I thought about it, but then we need to transfer such urls from backend to frontend, and decided to stick with strings as for other remote APIs.

@akosyakov akosyakov requested review from azatsarynnyy, kittaakos and svenefftinge and removed request for azatsarynnyy January 28, 2019 12:00
@akosyakov akosyakov changed the title [WIP] vscode built-in menus vscode built-in menus Jan 28, 2019
@akosyakov akosyakov force-pushed the ak/vscode_built_in_menus branch 2 times, most recently from 05e62e2 to 4f5e0ef Compare January 28, 2019 12:14
@@ -40,7 +41,9 @@ export class CommandRegistryMainImpl implements CommandRegistryMain {
this.delegate.registerCommand(command, {
// tslint:disable-next-line:no-any
execute: (...args: any[]) => {
this.proxy.$executeCommand(command.id, ...args);
// plugin command handlers cannot handle Theia URI, only VS Code URI
const resolvedArgs = (args || []).map(arg => arg instanceof URI ? arg['codeUri'] : arg);
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

@benoitf benoitf Jan 28, 2019

Choose a reason for hiding this comment

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

looks like there is something not so neat around URI. AFAIK consumer should just use the object

Copy link
Member Author

@akosyakov akosyakov Jan 28, 2019

Choose a reason for hiding this comment

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

it's not conflicting with https://github.com/theia-ide/theia/blob/master/packages/plugin-ext-vscode/src/browser/plugin-vscode-commands-contribution.ts#L46 ?

I don't think so. vscode.open is called by a plugin, so URI should be converted from VS Code to Theia format.

I'm trying to handle the reverse case: when Theia calls a plugin command. In this case, plugin command handlers expect only URIs in VS Code format, so Theia URIs should be always converted.

Does it make sense? Do you know the better place for conversion?

Copy link
Contributor

@benoitf benoitf Jan 28, 2019

Choose a reason for hiding this comment

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

thx @akosyakov for the reply. The location of the convert is still looking strange to me here.
AFAIK If someone is calling a plug-in then this is that part that need to convert to theia URI format, not theia plug-in checking if format that it is receiving is in a vscode format.

I'm afraid that we miss several converters. Here it is for Uri but what if there is another type, etc.
should it be inside RPC ? or is it mangled there https://github.com/theia-ide/theia/pull/4062/files

Copy link
Member Author

@akosyakov akosyakov Jan 29, 2019

Choose a reason for hiding this comment

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

AFAIK If someone is calling a plug-in then this is that part that need to convert to theia URI format, not theia plug-in checking if format that it is receiving is in a vscode format.

The core does not know that it calls a plug-in, it calls a menu command handler and pass URI of a selected resource to it. Usually it is fine. With plugin-in it is not, because they cannot handle such URIs.

Copy link
Member Author

Choose a reason for hiding this comment

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

Code in command-registry-main is a menu command handler from plugin-ins. Could you be more specific and suggest where it should be done if not here?

Copy link
Member Author

@akosyakov akosyakov Jan 29, 2019

Choose a reason for hiding this comment

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

Do you suggest to register a synthetic command for menu items that translates URIs and then delegate to a plugin-in command handler?

Copy link
Contributor

Choose a reason for hiding this comment

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

do you have an example of failing test for this usecase ?
is it only for vs code extensions or for theia plug-ins ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

@akosyakov
Copy link
Member Author

akosyakov commented Jan 29, 2019

@azatsarynnyy mentioned that there are duplicate menu items with these changes, for example for https://github.com/Azure/vscode-kubernetes-tools/blob/master/package.json#L579-L588 even though when context should ensure their uniqueness... i'm looking into it

@akosyakov
Copy link
Member Author

akosyakov commented Jan 29, 2019

@azatsarynnyy could you try again, i've removed a limitation to have only one menu item per a command. Since we have different contexts it does not make sense: 265c0e0

@azatsarynnyy
Copy link
Member

@akosyakov I've tested the PR with the latest version of the vscode k8s extension and it works well. I see no issues.

@akosyakov
Copy link
Member Author

@svor Could you check please that registering code lenses from the vscode extensions still work?

Copy link
Contributor

@benoitf benoitf left a comment

Choose a reason for hiding this comment

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

LGTM, thx

Copy link
Contributor

@svor svor left a comment

Choose a reason for hiding this comment

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

Tested with vscode java extension 0.37.0 and it works without unexpected problems

Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
…rent contexts

Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
@akosyakov
Copy link
Member Author

akosyakov commented Jan 31, 2019

  • update Changelog with breaking changes

Copy link
Contributor

@svenefftinge svenefftinge left a comment

Choose a reason for hiding this comment

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

LGTM

Signed-off-by: Anton Kosyakov <anton.kosyakov@typefox.io>
@@ -1,9 +1,20 @@
# Change Log

## v0.3.20
## v0.4.0
Copy link
Member Author

Choose a reason for hiding this comment

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

@akosyakov akosyakov merged commit d552d2a into master Jan 31, 2019
@akosyakov akosyakov deleted the ak/vscode_built_in_menus branch January 31, 2019 12:34
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.

[plugin] support VS Code built-in menu items
5 participants