Open afshin opened 8 years ago
Yep, and a lot of this refactoring will also help us in hooking up kernels to standalone text editors.
On Mon, Apr 11, 2016 at 1:17 PM, A. Darian notifications@github.com wrote:
In addition to the notebook interface, we need to implement a web-based version of the console interface. Here are some of the tasks that will get us there:
- Create a ConsolePanel as a container that holds a ConsoleWidget, similar to the way the notebook works.
- The first child of the ConsoleWidget needs to be a CodeCell
- The ConsoleWidget needs a set of keyboard bindings to emulate the Qt Console application.
- The execution of the code cell needs to be separated from the notebook because it is common functionality.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/jupyter/jupyter-js-notebook/issues/170
Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
@afshin,
Up/down at the edge of a codemirror: https://github.com/jupyter/notebook/blob/master/notebook/static/notebook/js/cell.js#L234
It looks like the current notebook is still using the deprecated payload
shell response for the pager:
https://github.com/jupyter/notebook/blob/master/notebook/static/notebook/js/codecell.js#L347
http://jupyter-client.readthedocs.org/en/latest/messaging.html#execution-results
cc @minrk
@minrk, ah, I see now "Payloads are considered deprecated, though their replacement is not yet implemented."
This statement is confusing, I would say it isn't deprecated until there is actually a preferred replacement.
@afshin, it looks like all of these will be relevant to you: http://jupyter-client.readthedocs.org/en/latest/messaging.html#payloads-deprecated
@blink1073 you're a monster. Thank you!
@blink1073 payloads are something that we don't like, and know that we will remove/replace when we get the chance. Since we know that, we want to avoid things like proposing new payloads, etc., but they still exist because we haven't come up with a replacement for the few things they are used for. If you have a better way to communicate "avoid using these if you can, but that's not always possible," A PR to the doc would be welcome.
@minrk in order to cover functionality that the Qt Console currently offers, e.g., using the interactive help
system, we'll need to use payloads. Do you have any input on how we should approach this?
cc: @blink1073 @sccolbert
Does the qtconsole use payloads to implement the interactive help? It looks to me like help()
just uses raw_input()
to do help. You can see that if you do help()
in the Jupyter notebook. It looks like you just have to implement the stdin connection: http://jupyter-client.readthedocs.org/en/latest/messaging.html#messages-on-the-stdin-router-dealer-sockets
@jasongrout pager output is a payload. @afshin yes, I think the frontend should support payloads. Sorry for the confusion. The comment in the docs mainly pertains to kernels, where we would like to avoid doing new things with payloads until we can come up with their replacement, express a preference to do things without payloads where there's an option.
@minrk Thanks for the clarification!
Ah, thanks for the clarification, @minrk.
FYI, this is the current state of affairs (which now includes history):
Nitpick from screenshots, Out[
don't have space before the square bracket to align.
@Carreau, thanks for the input. @blink1073 just created this issue for it: https://github.com/jupyter/jupyter-js-notebook/issues/221
The output input, as it were.
Current state of affairs:
Not sure if this is the right place to throw this in: It would be very handy to have the web console closely integrated with the notebook, e.g. through magic commands. Something like %qtweb
could spawn a console connected to the current kernel in a new tab or in an overlay. %qtdebug
might spawn a web console with %debug
executed inside, so that ipdb can be used with autocompletion and history.
Hi @jan-matthis, thank you, those are both excellent suggestions. We've moved development over to https://github.com/jupyter/jupyterlab. @afshin, do you want to migrate the top level comment over there and link to this issue?
@blink1073 @jan-matthis Sure, will do. Great suggestions.
Migrated to https://github.com/jupyter/jupyterlab/issues/76
In addition to the notebook interface, we need to implement a web-based version of the console interface. Here are some of the tasks that will get us there:
ConsolePanel
as a container that holds aConsoleWidget
, similar to the way the notebook works.ConsoleModel
that is similar to aNotebookModel
but does not have a notion of arbitrary cell insertion.ConsoleWidget
needs to be aRawCellWidget
to hold a banner and the second needs to be aCodeCellWidget
to hold the prompt.ConsoleWidget
needs a set of keyboard bindings to emulate the Qt Console application.prompt
execution, a newCodeCell
needs to be generated to become the newprompt
.pager
functionality of leaving the prompt and residing within a different interactive context (i.e., entering the interactive help) needs to be implemented.cc @blink1073 @jasongrout