Resolve the conflict run button in editor context menu

[jdneo]

Problem

Since the contribution point: editor/title is open for all the extensions, sometimes different extensions may have conflicts at this area. For example, in Java, such conflicts affect the run experience when the user installs both the Java extensions and the Code Runner extension:

This is a very open and big topic, as a author of VS Code extensions, it will be great if VS Code as a platform, can provide solutions for this issue.

Potential Solutions

Below are just rough ideas on this, it's open for discussion!

Editor Metadata

Extensions can register context value per document/editor, and register command on the editor title area according to the context value. For example. the Java Debugger can use this to mark if the current Java file is executable or not. And register the run/debug command into the editor context area if it's executable.

This can somehow achieved by using the in expression of the when clause, something like resource in hasMainMethodFiles. But we also need to get the context value dynamically from the code to handle with the corporation between multiple extensions.

Meanwhile the Java feature team can contribute changes to the Code Runner extension to align the UX (for example, hide the run button from Code Runner if the current Java file contains an executable Main class).

Official Support for the run experience in the editor title area.

This also may have some opportunity since I believe it's somehow related with #85759, if VS Code team will consider provide official run/debug functionality area in the editor title.

[egamma]

//CC @weinand

[jrieken]

From where I stand this looks like a feature for "Run & Debug", e.g not only have those commands in the views but also in editor titles. Tho, it would still mean that you have multiple "runners", just behind a nice UI.

[jdneo]

@jrieken Yes, if the VS Code platform can provide a UI to better organize different runners, that's great!

[weinand]

Currently VS Code debugging has no notion of "runners" because regular commands are sufficient to "run" something and there would be no additional semantics associated with those commands.

Adding the notion of "runners" as a debug specific tagging mechanism for commands in order to get a special UI treatment, sounds a bit like a hack to me.

Couldn't we not try to find a general solution to this problem?
E.g. something like this:

if multiple command contributions use the same icon, they are grouped together in a drop down menu that uses the same icon.

If this "implicit" grouping mechanism appears a bit too "magical", we could introduce a new "explicit" grouping property.

[jrieken]

If this "implicit" grouping mechanism appears a bit too "magical", we could introduce a new "explicit" grouping property.

Well, that would be a submenu, e.g we would define a submenu that sits in an editor title area and commands are contributed into that (instead of the editor title area directly).

Adding the notion of "runners" as a debug specific tagging mechanism for commands in order to get a special UI treatment, sounds a bit like a hack to me.

Assuming we have said submenu I think it would still be beneficial if debug contributes to that menu directly

[weinand]

And the submenu only appears if two or more commands are contributed to it? (and a single contributed command is shown directly in the editor's title area without the submenu?).

Assuming we have said submenu I think it would still be beneficial if debug contributes to that menu directly

individual debug extensions may contribute to the menu, but VS Code does not (because there is no generic "run")

[jrieken]

And the submenu only appears if two or more commands are contributed to it?

@joaomoreno knows the details here but it's up to us how we define the behaviour of submenus in toolbars

individual debug extensions may contribute to the menu, but VS Code does not (because there is no generic "run")

Yeah, that's what I mean

[weinand]

@joaomoreno does this proposal makes sense?

I propose that we address the issue of "conflicting run buttons" by a mechanism that automatically creates a submenu if two or more commands are contributed to the same "location" (or same contribution path, same ID, same icon etc.)

Since the resulting submenu shows the label instead of the icons, it makes the commands clearly distinguishable. If only a single command is contributed, no submenu is used and the command is directly shown in the editor's title area toolbar.

Since the submenu item needs an icon and probably a label, an open question is where does those come from?
Deriving them from the first command that goes into the submenu would result in an unpredictable UI. A better approach would be to explicitly contribute a submenu item (with icon and label), but keep it invisible as long as the there are no contributions to it.

[joaomoreno]

It makes sense, but requires implementing. This isn't the first time it's been asked for btw. Specifically:

1. If no actions are in the submenu, it doesn't appear at all
2. If one action is in the submenu, there is no submenu, only action
3. If more than one action is in the submenu, they appear as a submenu

Now, I wonder if this behavior should be an opt-in option on the submenu, instead of the default for all. I can imagine some situations in which having a dynamically changing UX is detrimental, since there's always the motivation to keep UI as stable as possible, especially around menus. Thoughts @jrieken?

[jrieken]

I propose that we address the issue of "conflicting run buttons" by a mechanism that automatically creates a submenu if two or more commands are contributed to the same "location" (or same contribution path, same ID, same icon etc.)

There should be no magic here, no comparing of ids or icons. What should happen is that extensions contribute their commands to a new menu, e.g. editor/title/run. We then render that menu as submenu in the editor title area using the smartness that @joaomoreno has described. Tho, it does mean that extensions need to adopt and contribute to the new menu, not to editor/title anymore

[jrieken]

Adding to January for exploration

[weinand]

Yes, no "magic". That was the conclusion of my proposal:

Since the submenu item needs an icon and probably a label, an open question is where does those come from?
Deriving them from the first command that goes into the submenu would result in an unpredictable UI. A better approach would be to explicitly contribute a submenu item (with icon and label), but keep it invisible as long as the there are no contributions to it.

[jrieken]

I can imagine some situations in which having a dynamically changing UX is detrimental, since there's always the motivation to keep UI as stable as possible, especially around menus. Thoughts @jrieken?

@joaomoreno I don't worry too much about changing UI. We already have that today, based on file type, being under git, etc. With when-clauses all the good and bad can be made and that won't change here.

[brettcannon]

FYI on the Python extension we actually hide our run button when we detect Code Runner installed; we use the colour of the button to help us tell which one people are using.

[jrieken]

@brettcannon you would still be able to do that but we ask you to contribute into the new submenu instead of the editor title menu

[jrieken]

This will be available to all extensions via the editor/title/run-menu

[DonJayamanne]

This will be available to all extensions via the editor/title/run-menu

@jrieken Does this apply to the Notebook Editor as well?

[jrieken]

Yes - all editors

[jdneo]

Thank you @jrieken ! 😄

One feedback: I tried to bind the keyboard shortcut to the command, but it's not displayed in the dropdown list. Is it by design?

[jrieken]

but it's not displayed in the dropdown list. Is it by design?

I guess but I would accept an issue for that ;-)