-
Notifications
You must be signed in to change notification settings - Fork 284
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
A new message type transient_display_data for transient information #378
Conversation
Can you summarize here some of the usecases for such a message? |
This message type contains transient information that are for information only. For example,
All these usages can be implemented with customized |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for opening this PR to kick things off.
docs/messaging.rst
Outdated
|
||
.. versionadded:: 5.3 | ||
|
||
This message is very similar to `display_data` but its is content is meant to be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd word this as:
The
transient_display_data
message has the same structure asdisplay_data
with one addition,title
, as well as a different intent. These messages are not to be persisted to notebooks or other formats. Examples of how this could be used is status of a long calculation as well debug information.
docs/messaging.rst
Outdated
|
||
Frontends can choose where and how to display and update `transient_display_data`. | ||
Due to the transient nature of such messages, a `transient_display_data` message | ||
would generally replace prior output although multiple messages with the same |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense if we used update_display_data
to target a transient_display_data
that was already on the screen? Then you'd able to update an individual output and maintain consistency amongst the other display_data
like messages.
I'm assuming you'd want to have a targeted clear_output
message too then to clear all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not seem to be a good idea to multi-purpose update_display_data
here, especially because there is no display_id
for transient_display_data
.
How exactly the messages should be aggregated (appended) and cleared depends on user interaction. I think the use pattern is generally something like this:
- User does something (e.g. executes a cell)
- Transient messages appear, and probably aggregate
- User consumes the message and performs the next action (e.g. modify the code and re-execute).
- A new batch of transient messages replaces displayed one.
So in my design:
title
shows the intent of one or more messages.append=true
would append message to a previous message with the sametitle
In practice:
- If a kernel wants to display some debug or progress information during the execution, it can send multiple
transient_display_data
with the sametitle
andappend=True
. - If a kernel would like to update previous message (e.g. new CPU/MEM status), it can either send a message with a different title, or the same title with
append=False
.
docs/messaging.rst
Outdated
content = { | ||
|
||
# Description of the data | ||
'title': string, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If multiple messages come in with different titles, do they each occupy new areas?
Is this regarded as a unique identifier then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my previous response. title
is intended to group consecutive messages with the same title
(and append=True
), very similar to the aggregation of multiple display_data
for the execution of the same input
. It is possible to keep (short) history of transient messages (e.g. a navigation button) but it would be easier to start with a single widget and see if there is a strong need from users to keep some sort of history.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, this is definitely getting used as a unique id then. It's both a display name for the user and the way it groups. I want to clarify that here in the doc if this is what you mean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do.
There is also another possibility for a kernel to send sticky transient information. For example, a So in case if there is really a need to keep some sort of log, a kernel can create a |
Considering the |
I frankly do not know anything about this |
The Payloads API is part of the core protocol, a bit of a carry over to make sure we still support being able to run for example:
to pull up help. |
Attaching
is sent from the kernel and creates or open a |
Proposal updated with a new |
There is a problem on how to handle
as
in |
JupyterLab inspector panel has a concept of |
I merged upstream/master and pushed a change to |
BTW, I Don't Like Notebooks - Joel Grus - #JupyterCon 2018 complains about no real time linter information, and this PR tries to solve it. |
… to display_data in content
@rgbkrk After some discussions during a JLab developer meeting, it seems easier to make |
b1fe8e4
to
3e8ee4a
Compare
A proposal for a new
transient_display_data
message type (#376) with content that is identical todisplay_data
. The messages are supposed to be displayed (or ignored) by the clients but not saved with the notebooks. This post list some applications of this message type.A
metadata
is allowed but no field is defined for nowUpdate Dec 2018: There has been some discussions about this message type in a JupyterLab developer meeting. The conclusion was that it is good enough (at least for now) to display the messages sequentially in a UI separated from the notebook so all the complex
title
,page
stuff are removed from the original version of the PR. A PR is submitted to JLab to display this message in console windows jupyterlab/jupyterlab#5699.Update March 2019: With the release of JupyterLab 1.0.0 alpha 3, a jupyterlab extension transient-display-data was released to send all
transient_display_data
to the console panel of notebooks. In addition, a new version of jupyterlab-sos was released to make use of this feature. The easiest way to test this feature is to go to our live server, start a notebook with a SoS kernel, open a console window, then execute the following trivial workflow in the notebook:The idea is that the console window will display progress information while the workflow is running.