Vscode: Allow extensions to add a floating button to specific files

[bpasero]

An ask from C++/Python extension. This is about allowing extensions to add a button similar to this ("Open Workspace") one:

[bpasero]

My comment:

This sounds like a horrible idea to allow for extensions to do because that basically opens the door for any extension to add a “Please donate” button into the editor.

Let me give more details why I think we should not do that:

• We have no story for when multiple extensions contribute to the same editor
• The action is not keyboard accessible
• The button never went through a UX design, we just added it a long time ago but never revisited its UI (e.g. it competes clearly with the toolbar we already have for editors in the top right corner)
• There is no way to turn off an extension from contributing UI pieces, so the more we allow to add, the more people might get annoyed by things an extension adds (yes, even if the extension is popular)

//cc @alexandrudima @jrieken

[isidorn]

@sean-mcmanus @WardenGnaw Here's is the alternative approach which I propose here
https://github.com/Microsoft/vscode/issues/65988#issuecomment-473248254

[greazer]

I don't see how this particular ask would be any more risky than many other extensibility point in VSCode. An extension writer could easily create scenarios to popup information messages, webviews, status bar messages, codelenses, heck even modal dialogs to annoy the hell out of users. I don't agree that this is a reason to not consider this proposal.

• "We have no story for when multiple extensions contribute to the same editor. "
  Sure. But we could consider limiting this functionality not to an entire file-type, but to specific files. This is actually the case right now for launch.json. The button only appears for launch.json, not ALL json files.
• "The action is not keyboard accessible"
  As long as there is an accessible way of doing the same thing as the button does, accessibility requirements are minimally met. If the lack of a better experience is deemed to be a problem, then certainly you need to address this current launch.json scenario, regardless.
• "The button never went through a UX design, we just added it a long time ago but never revisited its UI (e.g. it competes clearly with the toolbar we already have for editors in the top right corner)"
  It needs to be reviewed and adjusted if it hasn't been already. However, can you provide more detail or examples as to the "toolbar" you're referring to?
• "There is no way to turn off an extension from contributing UI pieces, so the more we allow to add, the more people might get annoyed by things an extension adds (yes, even if the extension is popular)"
  This problem has already existed for some time, and is likely not addressable without tyrannical control by VSCode itself. The C++ extension provides settings to turn enable/disable features it provided that conflict with features provided by other "competing" extensions. The Python team had to do work to adjust to older first-party extensions that provided similar features the Python extension has recently officially embraced. It seems highly likely that this is common occurrence, and will likely always be a problem.

I am no longer privy to exactly what the C++ team's needs are with regard to this specific request. However, the Python team is desperately looking for a way to allow users to be guided to edit a specific file type (sub-type to be more specific) that when saved and/or closed causes an event to occur in the extension that immediately drives further extension activity and potentially more user input. #65459. We've experimented with other vscode extension points and ideas, but have been unable to find a reasonable solution for our scenario. We're more than willing to do the coding to make any acceptable solution happen, but we want to be sure that the resulting PR will be approved.

[greazer]

@isidorn, thank you so much for the suggestion! But unless I'm missing something #65988 doesn't address our particular needs.

[EricJizbaMSFT]

I completely agree with @greazer that extensions can already abuse the system and be annoying. I also agree that the current button should go through a UX review and should be made accessible. As @greazer mentioned, this should probably happen regardless of if you add the extensibility point. Perhaps the ask shouldn't be "We want that specific button", but rather, "We want a very discoverable entry point to provide the primary action for a specific file".

For launch.json files, the primary action is to add a configuration. For *.code-workspace files, the primary action is to open a workspace. In my scenario, I want to add a button called "Add binding..." to "function.json" files in the Azure Functions extension. That file is very specific to Azure Functions and users have been complaining that editing a json file is not intuitive. I can add to the toolbar or context menus, but I just don't think those entry points are discoverable enough. When I say "primary action" I'm guessing that over half the time a user would prefer to click our button rather than edit the file directly.

There is no way to turn off an extension from contributing UI pieces

Yes there is, but the user has that control instead of VS Code. For example, our extension provides a custom tree view and VS Code lets users right click on that tree view to hide it. Perhaps part of the proposal/discussion should be a way to hide the button (or whatever entry point is added).

[sean-mcmanus]

@EricJizbaMSFT @greazer FYI, our C/C++ team is working on using a webview UI front end over our c_cpp_properties.json config file, similar to the one used by the CodeLens extension, so you may want to consider something like that -- UPDATE: VS Code doesn't want us doing that so we're considering alternatives (improving/extending their existing UI?). Another possibility might be to return diagnostics/squiggles and/or CodeActions/QuickFix results for that file.

[vscodebot[bot]]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!