Skip to content
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

Restoring option state on DynamicMaps #813

Open
jlstevens opened this issue Aug 16, 2016 · 5 comments
Open

Restoring option state on DynamicMaps #813

jlstevens opened this issue Aug 16, 2016 · 5 comments
Assignees
Labels
type: bug Something isn't correct or isn't working
Milestone

Comments

@jlstevens
Copy link
Contributor

This issue is in two parts, one requiring an easy fix and a second part that is more involved.

  1. When an exception occurs, the display hooks attempt to restore the option state using StoreOptions.state(element, state=optstate). When a DynamicMap is involved, this fails with StopIteration. This exception should be caught and silenced as StopIteration indicates there are no elements to traverse and therefore nothing to restore state on.
  2. Actually restoring the option state on DynamicMaps properly. DynamicMap requires special handling as the option state is held on the container and dynamically propagated to the elements as they are generated. StoreOptions.state therefore needs to be DynamicMap aware to handle this restoration properly.
@jlstevens jlstevens added the type: bug Something isn't correct or isn't working label Aug 16, 2016
@jlstevens jlstevens self-assigned this Aug 16, 2016
@jlstevens
Copy link
Contributor Author

jlstevens commented Sep 4, 2016

The above PR (#848) addresses part 1. though not in the way I thought it would. Catching StopIteration wouldn't be a good solution as it would mean that the style restoration would stop as soon as it encountered a DynamicMap.

Part 2. above will need to be addressed in a separate PR.

@jlstevens jlstevens added this to the v1.7.0 milestone Sep 4, 2016
@philippjfr
Copy link
Member

Will you tackle this for 1.7? Otherwise please postpone to 1.8.

@jlstevens
Copy link
Contributor Author

That depends on when 1.7 is ready: as soon as we have proper integration with Bokeh events, I feel we should release. This particular issue shouldn't block 1.7 but I would like to tackle it before then if I have time.

@philippjfr
Copy link
Member

Doesn't seem likely this will happen, and there's higher priority issues.

@philippjfr philippjfr modified the milestones: v1.8.0, v1.7.0 Mar 4, 2017
@philippjfr philippjfr modified the milestones: v2.0, v1.8.0 Mar 15, 2017
@philippjfr
Copy link
Member

@jlstevens Is this still needed? I don't quite remember if this is specific to the magics or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't correct or isn't working
Projects
None yet
Development

No branches or pull requests

2 participants