TextInput on_change behavior

Hi, I think TextInput’s behavior should be “on return”, not “on change”. It appears that when the input isn’t changed in the text input, a return does yield a call back action. This behavior is not desirable in a few circumstances. Occasionally, even if the text doesn’t get changed in the input, due to panning, zooming, etc., we want the callback to occur when we press return on the input field. Right now, this behavior is very frustrating. Simply deleting the text and retyping it doesn’t work. You will have to delete the text, click in an outside area, and refocus on the input field, type and hit return. Most users won’t be able to figure this out.

Secondly, this behavior makes AutocompleteInput 50% unusable on Safari. When you click on one of the suggested words, it won’t work.

My suggestion is: make the call back to occur on return, not on change.

Thanks.

Hi,

For feature requests and bugs, an issue on GitHub is much better:

  Issues · bokeh/bokeh · GitHub

It's easier to get other core devs into the discussion there, and, assuming the proposal is agreed upon, it's the right place to track and prioritize work.

Thanks,

Bryan

Did anything come of this? I’ve looked in github and don’t see this particular request. It looks like there was an issue for autocomplete in TextInput (#9046) but not for just hitting return.

My use case is providing a user module that people can dynamically load - and reload after changing. The loading works fine, but they can’t use the same name for the module in the text box (just hitting return), since nothing changed.

Or is there another way short of adding an explicit reload button?

Richard

As far as I can recall, no one ever made an issue. We are definitely at a point where new features need to have enough user interest/support that someone is at least willing to make a reasonably fleshed out issue to propose it.

So at present, a reload button is probably the simplest approach, though a custom extension is a more involved possibility.

I will say that this might be difficult to implement. The assumption that change events only fire on actual changes is buried very deep in the Bokeh codebase and disturbing it for this one use case might not be worth the risk/effort involved. But happy to discuss a proposal on GH, there might less invasive approaches (i.e. a new different property that counts <enter> hits that could be checked instead of triggering a change on the actual unchanged value)

Thanks, Bryan. I’ll go with expediency (a reload button) for now, and will submit a GH issue if it sounds like a new property might be feasible.

Richard

New property should be fairly simple. I’d regard it as slightly hacky but sometimes hacky is what can be accomplished. I suppose a slightly less hacky idea might be a new Event of some sort (now that events are an option).

I’ve submitted issue 9567.