Vote on new vscode esp-idf extension setup UI

[ESP_bignacio]

We have received a lot of feedback from you guys about configuring ESP-IDF extension for Visual Studio Code and how can be confusing for many users. We have designed a couple of interactive mockups with Figma to see which one you prefer for the new version of our extension. Please vote here for your favorite one.

Installer Style

This way tries to mimic a Windows Installer approach with Visual Studio Code UI layout.

QA Style

This way tries to get information about your setup using Questions like Do you have ESP-IDF installed ? providing options to use existing ESP-IDF folder or download (providing a install directory).

Please post your suggestions and issues here as well. Please no spamming, will delete any post that doesn't provide any actual feedback.

Brief explanation of the required steps of the setup:
1. ESP-IDF needs to be chosen or download in a given path to set $IDF_PATH.
2. Python path is required to create a python virtual environment that will be used for ESP-IDF, Debug Adapter and extension python packages. We have a standard to use $IDF_TOOLS_PATH/py_env/idfx.x.x_pyx.x where $IDF_TOOLS_PATH=$HOME/.espressif (%IDF_TOOLS_PATH%=%USERPROFILE%/.espressif in Windows) as default but can be modified. This is why this step has to be after IDF_PATH has been set.
3. ESP-IDF required tools such as xtensa-esp32-elf toolchain are required in PATH. We use $IDF_TOOLS_PATH/tools in the $IDF_PATH/install.sh or %IDF_PATH%/install.bat but on the extension we have allow user to manually set each tool path. (We had improve each path in a separated input field already in a PR in GitHub). If you manually define tools path out of $IDF_TOOLS_PATH/tools the behavior will be different from the command line
4. We can detect existing ESP-IDF, ESP-IDF tools if you have installed with $IDF_PATH/install.sh or $IDF_PATH/install.bat and use that, but we need to install Debug Adapter and Extension python packages requirements on top of ESP-IDF python packages.
5. We used to check python requirements in the extension setup with $IDF_PATH/tools/check_python_dependencies.py, but that seems to give many errors to users. Should we still check after installing ?

[username]

My vote is for "Installer Style". You get the best of both worlds. Express or Advanced install.

[boarchuz]

Hi Brian,
I've butchered your great mockups to present what would be, for me, a much more valuable concept (if you can look past the ugliness). It is based on a few assumptions:
1. People initially just want it to work with the least hair torn out as possible. Set up whatever is needed to get them building on the latest stable versions asap.
2. We will want to switch IDF/toolchain versions based on the current project. I know this is possible, but it's a little unwieldy at the moment. Sometimes I want to switch to master and build just to test the latest features/fixes; it seems unnatural going through an 'Onboarding' process to switch back and forth.
3. The extension may maintain its own private directory for the IDF, toolchain, etc. By taking advantage of git tags/branches it can expose different configurations to the user in a very friendly way that also allows for validating toolchain compatibility and so forth. It also ensures that all of the correct information about the environment can be included with shared projects and examples, so that they are more likely to build successfully.
4. Of course, users may want to add alternate paths to external IDF/toolchain.

https://www.figma.com/file/VDG206uteOMT ... tup-(Copy)
The first 2 show a very simplified onboarding. Set the location, and the extension does the rest (download; or, if everything already exists, skip; if dirty, re-download to known-good state).
The latter 2 show a (ugly) concept of changing the IDF 'Profile' for a specific project, with the extension providing a number of presets that automatically set the tools to the best compatible versions having simply selected the desired IDF version (eg. "master", "release/4.2", etc). Or, by toggling the switch, users can customise all of these (eg. by specifying a IDF commit ID; or by selecting one of their external IDF paths and specifying a branch; mixing and matching IDF/tool versions, etc).

(Sorry I know this is off on a tangent, feel free to disregard. And great work by all of you on the extension so far!)