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

Fix _SelectionModel and _MultipleSelectionModel to sync using indices #1262

Merged
merged 12 commits into from
Apr 10, 2017

Conversation

jasongrout
Copy link
Member

@jasongrout jasongrout commented Apr 6, 2017

Fixes #1091

CC @maartenbreddels

@maartenbreddels
Copy link
Member

If we sync label too, that would be useful in some cases, what do you think?

@jasongrout
Copy link
Member Author

@maartenbreddels, can you give this a try and see how it works?

If we sync label too, that would be useful in some cases, what do you think?

Possibly, though I don't like having two possibly conflicting sources of truth in the protocol, and it becomes confusing on who sets it (frontend or backend? Both I think have a valid usecase).

Make selection slider have a nonempty selection.
@jasongrout
Copy link
Member Author

If we sync label too, that would be useful in some cases, what do you think?

I'd much rather have the label derived from the index independently on the frontend and backend.

@jasongrout
Copy link
Member Author

Two design decisions:

(a) in this implementation, the default selection is no selection (except for the selection slider, which must have something selected

(b) We always coerce the options list to a ((label, value), (label, value)...) tuple. I think before it kept whatever object was originally assigned. I like this better - it emphasizes the ordered aspect of the options. However, for convenience, we still allow (and even expand) possible input types to include any mapping or iterable.

Thoughts?

We can still explicitly select no entry by having an empty options list or by explicitly setting the index, value, or label to None.
@jasongrout
Copy link
Member Author

(a) in this implementation, the default selection is no selection (except for the selection slider, which must have something selected

I went ahead and changed this to always select the first item (if there is a first item) on initialization or when changing the options. That seems to work better with interact, for example, where you just want some value by default.

However, I left the multiple select to still unselect all items when changing the options or setting it initially. Thoughts?

@jasongrout
Copy link
Member Author

However, I left the multiple select to still unselect all items when changing the options or setting it initially. Thoughts?

(This is a change - before, if the options changed in a multiple select, it would try to match up the previous selected labels to attempt to select the same items after the change. I think that is very error-prone.)

@jasongrout
Copy link
Member Author

Merging...let's iterate in another PR.

@jasongrout jasongrout merged commit c9d8088 into jupyter-widgets:master Apr 10, 2017
@jasongrout jasongrout mentioned this pull request Apr 18, 2017
@github-actions github-actions bot added the resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion. label Feb 16, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
2 participants