Finalize or remove the notebookControllerKind API Proposal
See original GitHub issueFrom https://github.com/microsoft/vscode-jupyter/issues/7373
Let’s figure out what to do with th notebookControllerKind
API proposal. Jupyter is currently the only consumer of it
@rebornix @DonJayamanne Can you please let me know:
- If/how Jupyter is using this API today
- If, in your opinion, this API should finalized or not? Are there any know issues / gaps with it
Issue Analytics
- State:
- Created 9 months ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Using Proposed API - Visual Studio Code
Proposed APIs are a set of unstable APIs that are implemented in VS Code but not exposed to the public as stable APIs...
Read more >Send a proposal | Buyer APIs - Google Developers
Sending a RFP to a publisher creates a Proposal and starts negotiations with a publisher. The following sample demonstrates how you can send...
Read more >Private Aggregation API - Chrome Developers
This API proposal provides one operation, sendHistogramReport() ... The Private Aggregation API design for FLEDGE has not been finalized.
Read more >Finish the Custom Fields API - Petitions - ClassicPress Forums
Fields API proposal for WordPress Core (2015-2017) - GitHub ... We would change the field definitions in our dev environment, ...
Read more >Finalize Draft Invoice with Stripe API - Pipedream
Finalize a draft invoice. [See the docs](https://stripe.com/docs/api/invoices/finalize) for more information.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@davidanthoff thanks for your feedback, they make good sense and we have discussed some of the wording, like using “Jupyter Kernel Specs”. We will address other feedback in issue https://github.com/microsoft/vscode/issues/168647
Actually, here is another idea: if the
notebookControllerKind
property were to be finalized, then we could start to use it with the previous iteration of the UI in the same way that the Jupyter extension is using it right now.In the new MRU UI, could the
notebookControllerKind
be the string by which the top level grouping happens? I.e. instead of using the description of the extension, or the name of the extension, could thenotebookControllerKind
be used if it is set?That would enable a scenario where things move forward now before the MRU story is finalized, and then there would also be a use-case for the
notebookControllerKind
in the new MRU UI.Also, I think this issue here is a dup of https://github.com/microsoft/vscode/issues/168535, but given that more discussion has happened here, it probably makes sense to close https://github.com/microsoft/vscode/issues/168535 and continue here.