If config provider has target platform/arch/config selection UI, ensure that's clearly disambiguated from cpptools config selection UI

[EpicRobertMillar]

Feature Request

I'm working on a configuration provider which will internally manage multiple target binaries/configurations/etc itself, and add a status bar item to expose this to users. This configuration provider could either be used by defining a single configuration in the c_cpp_properties.json file, or by allowing cpptools to automatically detect and use it.

In a scenario like this, it would be ideal if cpptools were to hide the default status bar item that it creates to avoid user confusion. I think this could also be useful for configuration providers for build systems such as cmake.

[EpicRobertMillar]

Just a quick update - I think VS code is performing better when using a single defined configuration with the configuration provider rather than relying on the autodetection, so it would definitely be nice to be able to hide the status bar item in the single-defined-configuration case.

[browntarik]

We are currently planning to move all of our status bar icons into a language status flyout panel (https://github.com/microsoft/vscode-cpptools/issues/8405). Would moving this button into that panel address your concern?

[EpicRobertMillar]

It sounds like we would also want the configuration provider's status bar items to appear inside that flyout, is that something that would be possible? I think we would still have confusion even if the default configuration button is inside the language status bar. The situation we would have is a button that says something like "UnrealEditor Win64 Development" in the status bar, and a button inside the standard language flyout that says "Win32".

[browntarik]

There are two possible solutions:

1. If you wanted to replace the default configuration (i.e Win32). The button would have a label next to it like "Active Configuration"
2. If the active configuration is a configProvider and there's only one, we can change the label to be "Configuration Provider" and list the name of the provider instead of the name of the cpptools config

Would either of these work?

[EpicRobertMillar]

Yeah, I think either of those would reduce the chance of confusion in a setup like this.

[browntarik]

Sounds good, the first approach will be supported in the language status flyout panel (https://github.com/microsoft/vscode-cpptools/issues/8405). This issue will be closed as a duplicate and you can track the other issue for more updates.

[Colengms]

Updating the title. Epic is looking at creating a custom config provider, which includes UI to switch between their own configurations (platform, debug/release). This experience will indeed be different after switching to using the language status flyout. Keeping this open 'just in case', as additional work/considerations may be needed to ensure users are not easily confused by multiple UI options all related to changing their "current configuration".