Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dependencies between kernel execution and UI #4623

Open
saulshanabrook opened this issue May 23, 2018 · 5 comments
Open

Dependencies between kernel execution and UI #4623

saulshanabrook opened this issue May 23, 2018 · 5 comments
Assignees
Labels
documentation status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@saulshanabrook
Copy link
Member

saulshanabrook commented May 23, 2018

During our meeting today, I brought up a request I had seen a couple of times (#4580, #3692) asking to be able to trigger some JupyterLab specific UI as the notebook executes. In this case, it was popping out an output into another window. Once the Javascript extension is merged (#4515), it would technically be very easy to provide Javascript output with a reference to the global application instance, which would let users do anything they want with in the JupyterLab frontend.

However, the consensus is that building official support for this would encourage creating notebooks that are JupyterLab specific and wouldn't be able to be supported by other frontends like nteract. The recommended approach is to create an extension, if you want to access the jupyterlab API.

In this case, it could possibly be an extension that handles a new mimetype by creating a new window for it and language specific wrappers that wrap outputs in this new mimetype. That would be easier for other frontends to also handle.

It would be good to document this rationale somewhere, maybe in the larger context of what features should be built into core vs what are better suited to third party extensions (at least at first).

EDIT: I am collecting issues that I think are related to this question of kernel execution being dependent on the frontend here:

@rgbkrk
Copy link
Member

rgbkrk commented May 23, 2018

Speaking as a developer on nteract and having fresh in mind why people elected building new APIs and UIs for jupyter, the reason you don't want your JS API exposed in outputs is for your own sanity. Someday you're going to want to change an API and you will be locked into past decisions or have to go the route of breaking things.

My opinion on the best way to handle this is to define metadata for the message spec for this. Note -- this use case is pretty similar to the proposal from @BoPeng in #4550

@ellisonbg
Copy link
Contributor

ellisonbg commented May 23, 2018 via email

@BoPeng
Copy link
Contributor

BoPeng commented May 23, 2018

kernels could send declarative JSON to run JupyterLab commands

This sounds a lot like the now deprecated "payloads" feature of jupyter messages. Learning how it was added and deprecated could help the discussion here.

@saulshanabrook saulshanabrook changed the title Document why calling jupyterlab APIs inside notebooks is note supported in core Document why calling jupyterlab APIs inside notebooks is not supported in core May 25, 2018
@saulshanabrook saulshanabrook changed the title Document why calling jupyterlab APIs inside notebooks is not supported in core Calling JupyterLab APIs in Notebook Outputs May 25, 2018
@saulshanabrook saulshanabrook changed the title Calling JupyterLab APIs in Notebook Outputs Dependencies between kernel execution and UI Jun 27, 2018
@blink1073 blink1073 added this to the Future milestone Sep 8, 2018
@lock
Copy link

lock bot commented Aug 6, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 6, 2019
@jasongrout jasongrout added the status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Aug 9, 2019
@krassowski krassowski reopened this Feb 16, 2024
@jupyterlab jupyterlab unlocked this conversation Feb 16, 2024
@krassowski
Copy link
Member

krassowski commented Feb 16, 2024

This issue is linked from documentation with "please comment here", it should not be locked.

Newer issue: #5789

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation status:resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

No branches or pull requests

8 participants