nbformat icon indicating copy to clipboard operation
nbformat copied to clipboard

Global output area for the notebook

Open SylvainCorlay opened this issue 8 years ago • 4 comments

This is something that has come up a few times in the past in discussions on various topics such as connecting multiple clients to a kernel and interactive widgets.

There should be a global output for the notebook, not only in the UI but also in the document format. For the following reasons:

  1. There are multiple cases where stdout / stderr messages are not uniquely bound to a cell of the notebook and are therefore lost to the user.
  • an output message broadcast from another client connected to a kernel (e.g. a console)...
  • an stderr / stdout message that comes from events that originated from a widget model message (and not a view) which are not bound to a cell.
  1. This information should probably part of the notebook format. This kind of notebook deserves to be saved as much as the cell output area.

If we do so, information such as the widget manager state could become global output instead of notebook-level metadata. Indeed such an output would be a more natural location for transient information than metadata, which conveys the idea of more static information.

Not all front-ends need to implement a UI for that notebook-level output area, but I imagine that it could be displayed optionally, or simply accessible through convenience js fonctions for people who work in the front-end.

SylvainCorlay avatar Dec 07 '16 00:12 SylvainCorlay

^ @minrk @takluyver

SylvainCorlay avatar Dec 07 '16 00:12 SylvainCorlay

As an addition to (1), anything that creates a child process that writes to stdout and stderr ends up not shown in the notebook (this is what @takluyver was hoping to address with the kernel nanny IIRC). I've been thinking about how I'd want general kernel output that didn't go over the normal messages to appear as a separate rolling log (like a side terminal). This would be useful for my current operations where a kernel runs on the JVM and generally has startup issues. If it can't even start then it doesn't even get ZMQ started and the user has no idea why the kernel is failing (and may not have quick access to the notebook server logs).

rgbkrk avatar Dec 07 '16 00:12 rgbkrk

On the scales of agreement, I'm not sure I believe in serializing a global output format. I am in agreement that there is a problem to solve here though. 👍

rgbkrk avatar Dec 07 '16 00:12 rgbkrk

This would be a single output area on the notebook, for example:

nb.global_outputs = [
    ...
]

otherwise identical to the .outputs list of a code cell?

minrk avatar Dec 07 '16 11:12 minrk