EditableText::new method to set initial text

[ickshonpe]

Objective

It should be simple to set an initial value for EditableText's text buffer.

Otherwise I can see users struggling with this and using some ghastly construction like a run once system in Update to set initial text.

Solution

New EditableText::new method. The value of the text buffer is set immediately and a TextEdit::TextEnd(false) edit is queued to move the cursor to the end of the text.

Testing

Added some initial text to the multiple text example:

cargo run --example multiple_text_inputs

[Zeophlite]

Might be worth adding a comment that it sets the cursor to start of text

[ickshonpe]

Might be worth adding a comment that it sets the cursor to start of text

Ah yeah that's a good point, I hadn't thought about the initial cursor position. I think that for new it's more natural for the cursor to be set to the end. That distinguishes it from placeholder text (when that is implemented) as well, where the cursor would be at the start position.

[viridia]

Another option is to initially have all the text selected. You often see this in prompt dialogs, where the text input is filled with some default string, but as soon as the user starts typing, the text is replaced.

Of course, the reason we even need any of this is because our text input is an uncontrolled widget. With controlled widgets, the buffer state is external and supplied by the user, so they can initialize it to whatever they want. For example, in the feathers color picker, the source of truth is not the text buffer, but the rgb value in the resource, which updates the buffer via change detection. And since change detection runs on initial creation, the text input gets initialized as we would want it to.

The downside of uncontrolled widgets is twofold:

• Every update has to emit an event which contains a complete copy of the pending changes. This is trivial for checkboxes and sliders, not so much for text inputs.
• The user has to handle this event, or the widget doesn't update.

In the documentation for headless widgets, it says that widgets are controlled, but I specifically call out an exception for text inputs, because I know that making them controlled is a problem.

[ickshonpe]

Yes Parley's PlainEditor is inherently stateful, so I guess we can only really work around it for the moment.