First I really like the move to a local IDE using Visual Studio Code.
What I currently do not understand is the strategy Particle Workbench uses with Particle Projects: It forces the creation of a Multi-root Workspace which is named after the Particle Project and the only project folder inside is again a root folder named after the Particle Project.
Further the Particle Workbench does not work with the workspace in the way that it supports multiple project folders/Particle Projects which is what I understand the Multi-root Workspace is intended for.
I think it’s due to the strategy that all the particle properties (like firmwareVersion, targetPlatform) are stored at the workspace level (<workspace>.code-workspace) and not at the project level (<project>/.vscode/settings.json).
In my opinion this strategy also causes some confusion with existing VS-Code users because normally you open VS-Code at a folder to work on that project. For a Particle Project (even if ist just one) you have to open VS-Code via the workspace file inside the project folder.
we went the current approach thinking we’d gain more predictability around configuration management while retaining the option to pull in additional directories on the user’s behalf and generally have more flexibility overall.
can you tell me more about how you use vscode workspaces in general? how do you envision workspaces working for the workbench? or are you suggesting they aren’t even needed?
I actually seldom use vscode workspaces. But for the Particle Workbench I wanted to use a vscode workspace for multiple Particle Projects. Concretely I wanted the three of my mesh Particle Projects (One project for Argon Gateway, One project for a Xenon Sensor Node, One project for a Xenon Actor Node) in one vscode instance to simply work on all of them from one workspace.
I have not fully thought this trough, but I think per default all particle settings (firmwareVersion, targetPlatform, targetDevice) should be at the project folder level. The only one that I see could make sense to be able to keep in sync over all the project and therefore at the the workspace level is the firmwareVersion, but its already more an optimization that the default.
The additional step does only appear when you have more than one project folder in the multi-root workspace. So for me this additional UX steps do not seem burdensome or confusing but rather a logical consequence of having more than one project folder, but I’m not a UX expert.