Skip to content

Improve UX if CustomConfigurationProvider is not ready yet #43

Open

Description

Hi,

Glad to discuss how could we improve PlatformIO's developer experience when using VSCode + "cpptools" extension. See scenarios below when is clear what to do for the end developer who faces the first time with VSCode/PlatformIO:

  1. Developer installs PlatformIO IDE for VSCode which depends on the "cpptools"
  2. Developer opens PlatformIO project downloaded from Git/Internet. At this stage, project dependencies (toolchains, frameworks, libraries) are not installed/ready.
  3. PlatformIO resolves all dependencies automatically by pulling packages from the PlatformIO Registry. It can take a few minutes depending on the project complexity.
  4. Developer tries to open any C/C++ files from the project AND!!! receives warnings about unresolved headers, broken syntax, etc. Of course, "cpptools" extension is right here because PlatformIO has not been provided configuration yet. It is still in progress, we download it...
  5. Developer STARTS filling c_cpp_properties.json because the "cpptools" extension forces him to do it. The developer does not understand what to do. No clue about toolchains, etc. Developer contacts PlatformIO forum or team and asks for help. Very often, developers even leave 1-star review as "it does not work".

So, how could we improve this API? The ideal scenario is to inform the "cpptools" that WE ARE ELIGIBLE to provide configuration but it can take us some time. See proposed workflow:

  1. PlatformIO extension starts and initiates api = getCppToolsApi
  2. At this moment, "cpptools" knows that there is someone responsible for the configuration and DOES NOT START its IntelliSense service waiting for the "command" when the provider is ready
  3. PlatformIO extension resolves all project dependencies, toolchains, and api.notifyReady(provider).
  4. Starting from this moment "cpptools" can complain about unresolved includes and syntax errors.

Your ideas?

P.S: As a workaround, I see that we can make a face configuration provider and provider "infinite sleep" to the provideConfigurations and other methods. Nevertheless, it is not useful from a technical perspective.


Related issue:

Activity

  1. sean-mcmanus commented on Jul 1, 2022

    @sean-mcmanus
    Contributor

    With CMake Tools, it will show a "Configuring project" status message in the bottom right, during which the user will still get errors about headers not found, but then those errors go away after the project is done configuring -- is that the same problem you're trying to resolve or not? This automatically gets fixed after waiting long enough so that may be why we haven't seen many user complaints about it. It sounds like the issue with users filling in the c_cpp_properties.json might be fixed by switching to the configuration provider API, since the configuration provider will override most of the entries added to the c_cpp_properties.json (as long as the configurationProvider property is set, and the configuration provider will automatically be used if it's the only one registered and there are no C_Cpp.default.* set).

    One could argue that if we didn't show "include not found" errors and instead just disabled IntelliSense, that users may then just switch to complaining about IntelliSense not working as expected.

    There is an additional potential issue if the configuration provider isn't able to be configured correctly or provide configurations for a certain file, in which case it might be desirable to falling back to not using the configuration provider (instead of disabling IntelliSense).

    I remember discussing this with Colen Garoutte-Carson (@Colengms) in the past.

  2. ivankravets commented on Jul 2, 2022

    @ivankravets
    Author

    is that the same problem you're trying to resolve or not?

    Yes, exactly.

    We don't propose to change the current behavior. It looks good for developers who manually install and configure this extension. Most PlatformIO users even do not understand that they use the VSCode code editor, not saying about the CPP tools extension. They are focused on project development where we solve configuration, and other hardware-related tasks automatically for them. Asking them to configure the "include path" is the same as when the operating system will ask me to debug its kernel. PlatformIO developers do not have information about build flags, include paths, and compiler. This information is dynamic and depends on the project working environment, where the project can have multiple of envs (different compilers, flags, etc).

    will show a "Configuring project" status message

    We show a similar message but in the bottom status bar. Not all developers see it. Maybe, we should show a popup notification to make it more visible. In this case, we can continue using c_cpp_properties.json.


    How is difficult to give us this control and don't provide any errors/ (Problems Tab) until we are configuring the project?

  3. sean-mcmanus commented on Jul 5, 2022

    @sean-mcmanus
    Contributor

    I'm confused by your statements "We don't propose to change the current behavior" versus "DOES NOT START its IntelliSense service waiting for the "command" when the provider is ready"...they seem contradictory.

    Instead of disabling IntelliSense, we could potentially add a command to the C/C++ extension that can enable/disable IntelliSense or just the error squiggles part, similar to the command we added at microsoft/vscode-cpptools#4893 , i.e. I don't think it would be difficult. That command would be outside of the vscode-cpptools-api.

    Yeah, CMake Tools shows the popup UI for their Configuring Project status.

  4. bobbrow commented on Jul 5, 2022

    @bobbrow
    Contributor

    Some of the reasons that cpptools goes ahead and starts IntelliSense even when a configuration provider is not ready is because:

    1. The developer expects it to start and we don't have many good UI options to let them know what's happening.
    2. We have to protect the experience from extensions that may be misbehaving and never return a configuration.

    When a configuration provider registers itself, I believe we are supposed to delay the notifications about "include path," but this could perhaps use some tuning.

    Some ideas of things we could consider that might make the experience better:

    1. Increase timeouts for "error" UI
    2. Disable red underlines temporarily while the configuration provider prepares itself
    3. Change the "include path" error to say something more useful, like that the [Foo] extension has not provided a configuration yet and you may experience IntelliSense issues in the meantime.
    4. Add a "loading" message or "progress" API of some kind that cpptools can use to surface information to the developer.
    5. Extensions can provide some "default" configuration for all files while it builds up the full configuration and then issue didChangeCustomConfiguration to let cpptools know to ask for a new config for those files when it is truly ready.
  5. ivankravets commented on Jul 26, 2022

    @ivankravets
    Author

    Some ideas of things we could consider that might make the experience better:

    Sounds great, this is precisely what I mean.


    I know you are very busy with the C/C++ extension. Let's keep this issue open and may be split into multiple feature requests. We followed Sean McManus (@sean-mcmanus) hints and added a progress notification (instead of windows's notification in the status bar) and meanwhile will stay with c_cpp_properties.json. It is more visible now. We hope this will help developers to understand that not everything is ready...

    Screen Shot 2022-07-26 at 12 31 48

  6. sean-mcmanus commented on Jul 26, 2022

    @sean-mcmanus
    Contributor

    Yeah, multiple feature requests would be easier to track/triage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions