Add combobox widget

[vidartf]

Based on adding a <datalist> tag to the <input> of the Text widget.

Fixes #1871.
Fixes #692.

[vidartf]

Commands to try in a notebook:

from ipywidgets import Combobox

Combobox(options=['Chocholate', 'Coconut', 'Vanilla'])

Combobox(options=['Chocholate', 'Coconut', 'Vanilla'], ensure_option=True)

[jasongrout]

Could we instead simply add a datalist attribute to the existing Text input?

[vidartf]

Sure, but that would change the logic some (options would default to None). Would you still always add the datalist tag, even if options is None? Or add/remove this tag as needed?

[vidartf]

And just for reference: What are the arguments for/against adding to Text vs keeping is separate?

[jasongrout]

I was thinking it would be easier for us to maintain and easier for the user (one widget instead of two). However, thinking out continuous_update - it should probably default to false for combobox, but already defaults to true for Text, so maybe that's an argument there for making it a subclass like you have.

Can you change the default for continuous_update? Especially if we're selecting from some options, we should only send a change if we're done selecting, rather than every keystroke.

[jasongrout]

Can you change the default for continuous_update? Especially if we're selecting from some options, we should only send a change if we're done selecting, rather than every keystroke.

And especially if one option is a substring of another. Continuous update true guarantees that we'll send the substring before the intended option if we are typing it out, which is probably not what is intended.

[jasongrout]

@SylvainCorlay - +1 for getting something like this in (however it ends up in) for 7.5.

[SylvainCorlay]

@SylvainCorlay - +1 for getting something like this in (however it ends up in) for 7.5.

Grumbles 😄

[vidartf]

@jasongrout / @SylvainCorlay This is already available as a separate package, so no rush from my side to get it in.

[vidartf]

@jasongrout Regarding continuous_update, there are two main modes for a combobox:

• Force the user to select one of the options. Here, continuous updates does not make sense. That is why setting ensure_option to true implies that continuous_update is ignored until a valid value is selected.
• Options are meant as hints for auto-completion, but free-form input is also valid. Here, continuous_update should behave as for Text (IMHO).

[vidartf]

And especially if one option is a substring of another. Continuous update true guarantees that we'll send the substring before the intended option if we are typing it out, which is probably not what is intended.

Hmm, this is a decent counter-example to what I wrote, but makes sense. It is also what I had originally intended (see docstring where it says that enure_option=True implies continuous_update=False).

[jasongrout]

Options are meant as hints for auto-completion, but free-form input is also valid. Here, continuous_update should behave as for Text (IMHO).

I think changing the user interaction behavior like this is confusing. I'd rather have continuous_update be explicitly set, rather than changing the default based on another option.

[maartenbreddels]

I am in favour for a separate widget, in most people's minds it is I think. At least in the frameworks I have seen, and in my mind :) (from mobile phone)

…

On Thu, 25 Apr 2019, 17:07 Jason Grout, ***@***.***> wrote: Options are meant as hints for auto-completion, but free-form input is also valid. Here, continuous_update should behave as for Text (IMHO). I think changing the user interaction behavior like this is confusing. I'd rather have continuous_update be explicitly set, rather than changing the default based on another option. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2390 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANPEPO4V5D7QH5TGEV5UTLPSHCMDANCNFSM4HIFE2JQ> .

[vidartf]

@jasongrout But I think the other option would still be needed, and that options will still be in conflict with continuous_update no matter what the default are.

[vidartf]

Use cases:

1. Alice wants a text box with some helpful suggestions (previous entries), but wants to accept new values as well. Also she ...
   1. ... does not need continuous updates, and also does not care if they happen or not, as she has a Button to indicate that she is done (has other input as well).
   2. ... only wants an update when the user indicates that she is done by completing input.
   3. ... needs continuous updates to perform some secondary action while inputting.
2. Bob wants to force the user to select one of his options, but prefers a ComboBox over a Select, as he wants the user to be able to quickly search by typing. As such, any partial value updates would break his logic.

[vidartf]

Are there any other use cases that I'm missing?

[vidartf]

I fixed some performance issues now as well, so now it should be able to handle options in the scale 10k-100k. The worst performance is when changing the options list, due to the large number of DOM-nodes that are added/removed.

[vidartf]

ping @jasongrout ;)

[vidartf]

pong @jasongrout

[jasongrout]

I won't be able to review this before 7.5, but it looks like Sylvain is on a review/merge roll.

[jasongrout]

CC @SylvainCorlay

[SylvainCorlay]

@vidartf I am fine with merging the current state of the code. We probably want to have a docstring instead of a TODO statement for the release though. Do you have a bit of time to add something there?