Handle varying buildConfigurations in the Recipes Explorer

[LiveFreeAndRoam]

Firstly, thankyou for this extension. It is impressive! It takes lots of the tediom out of everyday yocto activities.

Environment

I'm using v2.7.0 (the latest currently available). I have a multiple-machine configuration with thousands of recipes for each machine, although I work on about a dozen recipes at a time.

Issue

In the Yocto-Recipe explorer, I can see recipes listed for each machine, however only recipes for the selected machine are "active", meanwhile recipes for the inactive MACHINE are displayed as "Recipe not found" (see image below). I have to switch back and forth between each MACHINE and then refresh the RECIPE EXPLORER view to see all the recipes. This is a daunting task.

Proposed Solution

Ideally, the MACHINE name could be introduced as a top-level node in the RECIPES EXPLORER hierarchy. E.g.

MACHINE1 > recipe1
         > recipe2
         > recipe3
MACHINE2 > recipe1
         > recipe4

I need all MACHINE configurations to be active (scanned and parsed) simultaneously. At the moment, I have to select the MACHINE and refresh RECIPE EXPLORER, which triggers bitbake scan and parse, to view each machine's set of recipes. E.g. from the above structure, to view recipe4, I need to make MACHINE2 active, refresh RECIPE EXPLORER. Switching back and forth between MACHINEs to see each of the recipes becomes a daunting task.

UI/UX Feedback

If there is still a need to activate just one machine, then I have a some UI/UX feedback:

1. Display the active machine adjacent to the RECIPES EXPLORER. Currently, the default screen layout has the RECIPES EXPLORER panel in the top-left and the active machine in the bottom-right of the status bar. On a big screen, I have to scan corner-to-corner to confirm which machine is active for the set of recipes.
2. Cache bitbake scan and parse results so that I can switch between machine's without needing to refresh RECIPE EXPLORER.
3. Use a different color for active and inactive recipes (or perhaps machine-specific colors). This will make eyeballing the recipes explorer much more efficient.

Recipes not found for inactive machine

You can't see which machine is active by looking at the RECIPE EXPLORER. Also, recipes that are not part of the active machine show as "Recipe not found".

[deribaucourt]

Hello, your feedback is greatly appreciated!

We actually do support showing recipes for inactive MACHINEs since the last update. They are reported as "skipped" in the Recipes Explorer view:

However, what we don't support currently is listing recipes for other bitbake.buildConfigurations settings that use a different set of layers. I guess this is what you are experiencing? In that case indeed, the recipes are not visible to our project scan because it is only based on the currently selected configuration. This hasn't been reported as an issue by users so far because most of the time, various distro/machine configurations share the same layers.

I think the reasonable way to implement what you want is indeed to cache the scan results for each configuration and display the proper results when configurations are swapped in the bottom right selector. It's an interesting feature to add to our backlog I think 👍 . It will also make the views more accurate by automatically triggering rescan/cache swap instead of relying on the previous configuration.

Regarding the UI/UX, my suggestion would always use the same colors, except the contents would now always be aligned to the selected buildConfiguration. And currently unavailable recipes would still appear as "not found" which may hinder your browsing experience... But I find it a bit tricky regarding accuracy if we keep showing it even though its no longer part of the bblayers in scope. You could still use Ctrl+Shift+P, or the file browser to access your recipes quickly.

For your 1., the buildConfigurations selector is at the bottom right because its the conventional VSCode presentation to pick configurations (debug configurations, CMake configs, C++ configs, Python virtual envs...). We could also remind it in the title of the recipe explorer view. Could also add a button in that hotbar to trigger the "change configuration" command.

[LiveFreeAndRoam]

However, what we don't support currently is listing recipes for other bitbake.buildConfigurations settings that use a different set of layers. I guess this is what you are experiencing?

Yes, that describes my environment.

I think the reasonable way to implement what you want is indeed to cache the scan results for each configuration and display the proper results when configurations are swapped in the bottom right selector. It's an interesting feature to add to our backlog I think 👍

I look forward to one day seeing it appear in my daily workflow. Thanks!

Regarding the UI/UX, my suggestion would always use the same colors, except the contents would now always be aligned to the selected buildConfiguration.

Yes, I agree that having recipes listed under each buildConfigurations is much preferred over using colors.

Related to this is the "Recipe not found" message. For those recipes that have problems, I have to open the recipe folder to discover that the bitbake file is not found. Perhaps there can be some indication that a recipe has problems without me needing to open it? In other words, lift indications of problems in recipes up to the recipe folder.

We could also remind it in the title of the recipe explorer view. Could also add a button in that hotbar to trigger the "change configuration" command.

I like both of these options 😀.

Thankyou for your consideration.

[deribaucourt]

Related to this is the "Recipe not found" message. For those recipes that have problems, I have to open the recipe folder to discover that the bitbake file is not found. Perhaps there can be some indication that a recipe has problems without me needing to open it? In other words, lift indications of problems in recipes up to the recipe folder.

Sounds good, we could use a "warning" symbol, just like for the "skipped" recipes. To have the recipe file available, you would need to switch to the proper buildConfiguration.

[deribaucourt]

Implementation breakdown:

• Store BitbakeScanResult as an array per buildConfiguration in BitBakeProjectScanner
• Getter function will return the active scan result
• When selecting a new buildConfiguration, trigger a project scan if not already cached
• When selecting a new buildConfiguration, refresh the bitbake tree views
• Add the selected buildConfiguration name to the title of the Bitbake view panel
• Add the pick-configuration command to the long actions menu of the recipe tree view (a new hotbar action would break UX guidelines)
• Use a Warning icon in the recipes tree view for recipes which are not found