Widget adaptor for string parsing

[Ralith]

Useful for e.g. text boxes intended to contain integers.

[Ralith]

It's tempting to try to derive a Lens-flavored solution to this problem rather than a widget adapter, but the path forward there is less clear to me. A similar impl Lens<T, String> could be defined easily enough, but dropping writes violates the traditional lens laws. Maybe we could start establishing prism-inspired patterns, but I'm not sure what that would look like.

[futurepaul]

I love this API, seems especially slick for Label, but I'm not sure if it's quite functional enough to be good for numeric textboxes. The feedback loop of parsed data modifying the state of the textbox that's trying to modify the state just doesn't quite work in practice. Perhaps additional functionality here, or additional functionality in textbox, could correct for that?

[Ralith]

I actually built this for, and am using it with, text boxes, but on closer examination I see that you get a panic if the text box becomes empty. Maybe adapt Option<T> instead of T? Or even Result<T, <T as FromStr>::Error>?

[Ralith]

One problem with this approach is that it's impossible to input values for which there isn't some edit path from the current value to the desired value where every step is syntactically valid. Instantly rejecting invalid inputs is cute for things like integers, but e.g. inputting 1e10 for a float would be impossible. I think I'll reprise this to preserve invalid values internally.

[cmyr]

yea, you beat me to it there. I don't think FromStr is an appropriate tool for this, because of intermediate states. IIRC there's a very good cocoa API for this stuff, let me try and dig it up

[cmyr]

So I'm thinking of NSFormatter and NSNumberFormatter. The best overview is probably here. We don't need to do all of this, of course, but it hopefully provides a good overview of the problem.

So I think we want some sort of 'validator' type. There should be two validation steps: during editing, we should check for the validity of a partial string, and then when editing ends we should check for the validity of the final string.

there's lots of subtlety, here. is 1 000 a valid number? is 1,000? is 001? Should we take the current locale into consideration during parsing? etc etc. I think that we can keep a first implementation is simple as possible, but these are things to keep in mind.

[Ralith]

Wasn't able to reproduce the panic. For posterity:

thread 'main' panicked at 'byte index 2 is out of bounds of `1`', src/libcore/str/mod.rs:2051:9
<snip>
  18: core::str::traits::<impl core::ops::index::Index<I> for str>::index
             at /rustc/4560ea788cb760f0a34127156c78e2552949f734/src/libcore/str/mod.rs:1657
  19: unicode_segmentation::grapheme::GraphemeCursor::prev_boundary
             at /home/ralith/.cargo/registry/src/g.yxqyang.asia-1ecc6299db9ec823/unicode-segmentation-1.6.0/src/grapheme.rs:639
  20: druid::widget::textbox::prev_grapheme
             at /home/ralith/src/druid/druid/src/widget/textbox.rs:489
  21: druid::widget::textbox::TextBox::backspace
             at /home/ralith/src/druid/druid/src/widget/textbox.rs:204

I went ahead and reworked this with the Option concept; the user's input is now only modified on update, never during event, and parse errors yield None.

This is obviously not touching at all on the questions you're raising regarding rich formatting, internationalization, and dynamic user-visible validation. I think those are important things to have, but maybe this very simple approach is still useful in the meantime/for simple cases?

[cmyr]

@Ralith can you use this widget in one of the examples, so it's easier to play around with/test?

[Ralith]

Done, along with a tweak to fix some poor behavior thereby identified.

[cmyr]

Okay, I can see this having some value, although I suspect we will want something more flexible before too long? In particular I think the fact that a parse failure deletes the existing data might be a liability. In any case, not hard to deprecate it down the road.

[cmyr]

I would explicitly document that this works with the FromStr trait, and that T has to be a type that implements FromStr.

[cmyr]

@Ralith this looks ready to go?

[Ralith]

Yeah; looking forward to a better solution, but in lieu of infinite free time there's no sense blocking a simple one.