You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
works fine in the way many users expect, but in JupyterLab and CoCalc Jupyter it does not. This is by design in JupyterLab. Jason even convinced me that JupyterLab makes the right choice, with a planned log screen.
However, further discussions with multiple Jupyter frontend devs and users, have convinced me tha the original Jupyter classic widgets behavior is what people expect, and that's what I will be implementing in CoCalc. Not only that, but this is a very high priority.
For example, recently a Jupyter dev demoed cocalc to a company and the example above just happened to be the first thing he tried, and it totally failed, making him believe cocalc was completely broken. NOT GOOD. And when I explained the log idea, he considered it a nonstarter given the target audience of widgets. I also just asked in the abstract another developer what they expected to happen (laying out a few options, including the log and the jupyter classic behavior), and again, they said definitely the Jupyter classic behavior, and that is what they would be implementing in their own new widget implementation.
I also mentioned @jasongrout's argument "However, for other widget messages that don't originate from a specific view (e.g. with a webcam widget that would capture the webcam input), where should the message be displayed?" to each of these people, and they were not convinced, given how special / impossible of a case that is, given the non async nature of python (and in that case, you use an Output widget).
The text was updated successfully, but these errors were encountered:
FYI, JupyterLab 1.2 or later (recently released) has an initial implementation of this log idea. Any output or errors from such code are displayed in a new log console, which has a flashing indicator on the status bar, or can be opened explicitly from the View menu.
Just came across this issue made the comparison Google Coolab - VS Code - JupyterLab (December 2023):
widget.mov
Both Google Coolab and VS Code print directly into the output, and I think that behavior is more intuitive as well.
Also, the console is quite hidden in View-> Show log console.
Therefore my question: Would it be possible to make printing into the output the default in a future JupyterLab release?
Definitely even today CoCalc just silently ignores such output. This is how to accomplish things using an actual output, by the way:
importipywidgetsaswidgetsout=widgets.Output()
defsay_hi(b=''):
without:
print('hi', b)
out---button=widgets.Button(description='click to say hi')
button.on_click(say_hi)
button
In Jupyter classic this example:
works fine in the way many users expect, but in JupyterLab and CoCalc Jupyter it does not. This is by design in JupyterLab. Jason even convinced me that JupyterLab makes the right choice, with a planned log screen.
However, further discussions with multiple Jupyter frontend devs and users, have convinced me tha the original Jupyter classic widgets behavior is what people expect, and that's what I will be implementing in CoCalc. Not only that, but this is a very high priority.
For example, recently a Jupyter dev demoed cocalc to a company and the example above just happened to be the first thing he tried, and it totally failed, making him believe cocalc was completely broken. NOT GOOD. And when I explained the log idea, he considered it a nonstarter given the target audience of widgets. I also just asked in the abstract another developer what they expected to happen (laying out a few options, including the log and the jupyter classic behavior), and again, they said definitely the Jupyter classic behavior, and that is what they would be implementing in their own new widget implementation.
I also mentioned @jasongrout's argument "However, for other widget messages that don't originate from a specific view (e.g. with a webcam widget that would capture the webcam input), where should the message be displayed?" to each of these people, and they were not convinced, given how special / impossible of a case that is, given the non async nature of python (and in that case, you use an Output widget).
The text was updated successfully, but these errors were encountered: