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

Add a continuous_update option for text widgets #584

Closed
jasongrout opened this issue May 13, 2016 · 9 comments · Fixed by #1545
Closed

Add a continuous_update option for text widgets #584

jasongrout opened this issue May 13, 2016 · 9 comments · Fixed by #1545
Labels
feature request good first issue resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Milestone

Comments

@jasongrout
Copy link
Member

The sliders have a continuous_update option that only triggers a value change when the user stops dragging a slider: https://github.com/ipython/ipywidgets/blob/master/ipywidgets/widgets/widget_int.py#L155. Likewise, the text boxes should have an option to only update the value when the text box is blurred, or maybe when the user presses enter in a one-line textbox (sort of the equivalent of the on_submit handler textboxes currently have).

@dhirschfeld
Copy link
Contributor

dhirschfeld commented May 15, 2016

An event which triggers on enter or when a user leaves the text box would be useful. The current on_submit can be confusing if the user forgets to press enter, the text has changed but the handler hasn't triggered so the text in the box won't necessarily be related to the state of the widget.

Or perhaps some sort of validation to highlight the fact that the text has changed but the change hasn't been submitted yet.

@jasongrout
Copy link
Member Author

+1 to the UI indication of a 'dirty' textbox.

@codypiersall
Copy link

+1 for this! I wrote a notebook that uses ipywidgets to control a motor, and had to use a Text widget because the hardware would ignore commands while it was already doing something. But a BoundedFloatText was conceptually better! @dhirschfeld's idea is perfect -- update when the box loses focus or the user hits the return key.

Would a pull request implementing this be likely to be merged?

@jasongrout
Copy link
Member Author

Would a pull request implementing this be likely to be merged?

Yes, very likely!

@codypiersall
Copy link

I'd love to work on this, but if someone else wants to please go ahead! I probably won't have time for about the next month, but after I'm done with my current side project I'll give this a whirl. All this to say...

If someone comes across this post in about a month and I haven't re-posted, feel free to ping me!

@jasongrout
Copy link
Member Author

Thanks! I've also marked it as sprint-friendly, so it'll be easier for new contributors to find.

@jasongrout
Copy link
Member Author

ping @codypiersall, as requested. Someone else just asked for this today too.

@jasongrout jasongrout modified the milestones: 7.0, Future Jul 26, 2017
@jasongrout
Copy link
Member Author

To implement this, I would:

  1. Make a continuous_update attribute analogous to the slider's attribute at
    continuous_update = Bool(True, help="Update the value of the widget as the user is holding the slider.").tag(sync=True)
    on the textboxes ( ,
    class Textarea(_String):
    ,
    class FloatText(_Float):
    ,
    class BoundedFloatText(_BoundedFloat):
    , and the inttext widgets too)
  2. In the javascript code to each of the views, handle continous updates with the input event, and non-continuous updates with the change event.

@SpyrosPetsis

This comment has been minimized.

@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 7, 2021
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 7, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature request good first issue resolved-locked Closed issues are locked after 30 days inactivity. Please open a new issue for related discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants