-
Notifications
You must be signed in to change notification settings - Fork 947
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
Should "Save Widgets" be a checkbox? #1632
Comments
Thanks - this makes a lot of sense if there are the appropriate notebook hooks. |
I'll look into this. |
Thanks! |
As requested by @Madhu94 let here is a summary of my suggestion in #1952: It think the notebook regular button should perform these operations in sequence:
so that widgets
|
Would it be useful to have this information persisted in the user's config files? |
I am not sure what you mean exactly by user's config file. |
Oh sorry, I was referring to the addition of a checkbox to save widget state by default. When the user makes a choice to leave this checked or not, should we save this choice somewhere (like in |
Ah ok ! Then I think yes. |
Cf. issue jupyter/nbconvert#751 as several people (incl. me) would like to be able to save widget state from nbconvert. |
It looks like there are appropriate hooks in the classic notebook: There is an event that the notebook triggers before saving - perhaps in the widgets menu we have a setting (i.e., menu item with toggle checkmark) that automatically saves the widget state when you save the notebook. This goes along with #2012. |
I arrived here looking for issues and discussion regarding widgets state in notebooks. Has there been a debate to save the widgets state by default? I find the current behavior, plus the lack of support for ipywidgets >= 7 in nbconvert, suboptimal. |
I agree that saving widget state by default would make the most sense. Having a checkbox (default checked) would allow those that don't want the state saved the option. (But I'm not sure of the use case for not saving? Is there one? There was a bug previously that state kept accumulating. Is that still a problem?) |
I wonder the same thing. Right now, what I usually do is:
|
We used to save the widget state by default. However, in most of the use cases we saw, widgets were used as transient guis that didn't make sense when the notebook was opened again, so there was little benefit to the constant churn and bloating of notebooks with widget state. I like the simplicity of a checkbox, but I think I would default to off rather than on, or at least make it a user-defined setting whether it should default to off or on. |
As far as I can see, often in my company, ipywidgets are used as (dynamic) illustrations and people expect them to persist just like say matplotlib pictures. For those who specifically want to save light notebooks, they 'clear all outputs/widget states'. For the users I know both of these actions could be merged. More importantly, It think it is really crucial that people running notebooks programmatically and snapshoting them as html pages (using nbconvert) can save widget states. I don't think this is possible now and it is a serious limitation to that sort of power user. |
At the tutorials at scipy I also had to explain this, I think it would be more natural for them to be included. We could optimize it a bit, by 'tree shaking', finding widgets that are not linked to any widget that has a view. I would also find a opt-out option more logical, you expect output all to be included in the notebook, and if it becomes huge/large/slow, you'll need to find ways to circumvent this, i.e. disable it. |
(Simple) code for this is already in the embed module |
Yes, that code comes from ipyvolume, but it is kernel side. For this, I guess we want something similar for the front-end. |
Another idea would be to have some sort of warning before closing the tab, saying something like "Hey, are you sure you don't want to save the widgets state? It will be lost if you don't (check here to disable future warnings like this)". This does not require any change in the backend logic but would be a big usability improvement for fools like me (yes, I've been hit by this today again). |
Wondering: does JupyterLab have the same "issue"? |
Issue started here: jupyter/notebook#2735
The text was updated successfully, but these errors were encountered: