-
Notifications
You must be signed in to change notification settings - Fork 1
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
Visualization state can be captured and reloaded by anyone #18
Comments
Do you think this needs to be in the URL or is it enough to have an area on the site to copy/paste the state? I think Neuroglancer has moved away from putting it all in the URL but I'm not sure (that might have been one of the forks). It is probably not an issue here given we will have much less state. We could probably support both. Do we want it to be human-readable or what do you think of base64-encoding the state? |
Not necessarily, so I updated the title and description appropriately. I think it should be a goal to have some way of sharing a URL to reproduce visualization state (e.g. so that a preprint could just link that URL), but that doesn't have to be the only way to share and the content doesn't need to be human-readable. |
Summarizing some discussion elsewhere, there's a stronger desire to have the URL contain the necessary state here (rather than have somewhere to put the state in to load). But it's OK if that state is byte-encoded rather than a readable JSON string (since with enough state, that becomes pretty unreadable). |
This provides a simple way to share state between two instances of the tool. It captures most of the current state we care about persisting, with the exception of selection because that is timing/order sensitive and may need some related cleanup before we use it as a shareable state. The approach defines a dataclass for serializing/deserializing the state from the URL's hash. I don't love it because it requires some boilerplate in the class itself and related book-keeping elsewhere (in `state.tsx`) but I think it's probably good enough for now. Open to better ideas though! I encoded the state using `URLSearchParams` to sanitize the strings for usage in a URL. Alternatively, we could use a base64 encoding of the JSON string which could also simplify the (de)serialization code, though will likely be longer than the current encoding. Closes #18 --------- Co-authored-by: Ashley Anderson <[email protected]>
The goal of this issue to allow users to capture the state of the viewer and share that with other users to reproduce that state/view. Not all state has to be captured to start, but maybe a good initial goal to have dataset, time-point, camera parameters, and selection.
This could be done by embedding that state directly in the URL as a JSON string, but other options could also be considered (e.g. base 64 encoding of state, copy state into a dedicated edit-box).
The text was updated successfully, but these errors were encountered: