You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In microsoft/vscode-jupyter#11904 we are exploring improvements to the kernel picker. Current kernel picker presents all kernels in a flat list, it works well for scenarios where kernels are fixed (e.g., .NET) but it's not great when the kernel list is dynamic and involves user interaction. The Jupyter extension supports to use local Jupyter kernel specs, existing Python environments on user's system, or any remote Jupyter server(user provided or offered by 3rd party) as execution engine (i.e., kernels), but users find them often lost in either long list of all available kernels.
Here we want to explore a MRU list for kernels when users switch between various kernels for different purposes, hiding kernels that are not frequently used, or only create kernels/controllers when they are manually picked. It will cover following basic scenarios:
New user
Users would see suggested kernels from notebook extensions they installed
Kernels whose relevance to the active notebook/environment are folded into action More Kernels (${count} ...) and users can browse them by picking this action
If users are not happy with either, they can still choose to create new Jupyter kernels through the action Select another Jupyter kernel contributed by Jupyter extension, through which they can use a Python environment as a kernel, connect a remote jupyter server, or start a new Jupyter server from GitHub/AZML.
Second time +
Once users pick a kernel and use it, VS Code will cache the user selection and generate a MRU list based on the kernel selection history. Next time when users open a new notebook, VS Code will present the top N items in the MRU list to users
In addition to above basic scenarios, we also need to ensure that
This new experience will be behind a setting/experiment and we would also migrate users existing kernel selection history to the new MRU list, users should take no extra step to use the previously selected kernel to run code, until they decide to switch to another kernel.
Extension which contribute NotebookControllers to their own custom notebook shouldn't have a degraded experience with the new MRU experience.
The text was updated successfully, but these errors were encountered:
In microsoft/vscode-jupyter#11904 we are exploring improvements to the kernel picker. Current kernel picker presents all kernels in a flat list, it works well for scenarios where kernels are fixed (e.g., .NET) but it's not great when the kernel list is dynamic and involves user interaction. The Jupyter extension supports to use local Jupyter kernel specs, existing Python environments on user's system, or any remote Jupyter server(user provided or offered by 3rd party) as execution engine (i.e., kernels), but users find them often lost in either long list of all available kernels.
Here we want to explore a MRU list for kernels when users switch between various kernels for different purposes, hiding kernels that are not frequently used, or only create kernels/controllers when they are manually picked. It will cover following basic scenarios:
New user
Users would see suggested kernels from notebook extensions they installed
Kernels whose relevance to the active notebook/environment are folded into action
More Kernels (${count} ...)
and users can browse them by picking this actionIf users are not happy with either, they can still choose to create new Jupyter kernels through the action
Select another Jupyter kernel
contributed by Jupyter extension, through which they can use a Python environment as a kernel, connect a remote jupyter server, or start a new Jupyter server from GitHub/AZML.Second time +
Once users pick a kernel and use it, VS Code will cache the user selection and generate a MRU list based on the kernel selection history. Next time when users open a new notebook, VS Code will present the top N items in the MRU list to users
In addition to above basic scenarios, we also need to ensure that
NotebookController
s to their own custom notebook shouldn't have a degraded experience with the new MRU experience.The text was updated successfully, but these errors were encountered: