Make FeathersTextInput include its container

[0xEgao]

Objective

Fixes #24882

Solution

I’ve tried the following changes:

• Made FeathersTextInput include the decorated container by default.
• Synced InteractionDisabled with the editable child.
• Updated the gallery and number input to use the new API.

Added :

• input prop: Necessary to preserve customization of EditableText after it becomes a child entity.
• leading_controls: Necessary to support prefixes such as search icons or labels.
• extra_controls: Necessary to support suffixes such as clear or visibility buttons.

Happy to adjust these if this approach does not fit well.

Testing

Ran:

• cargo fmt --check
• cargo check -p bevy_feathers
• cargo check --example feathers_gallery --features bevy_feathers
• cargo check --example feathers_number_input --features bevy_feathers
• cargo clippy -p bevy_feathers --all-targets -- -D warnings

Showcase

Previously, a decorated text input required manually composing both entities:

@FeathersTextInputContainer
Children [
    @FeathersTextInput
]

The container is now included by default:

@FeathersTextInput {
    @leading_controls: bsn! {
        caption("#")
    },
    @input: bsn! {
        HexColorInput
        on(handle_hex_color_change)
    },
    @extra_controls: bsn! {
        @FeathersToolButton
    },
}

Specialized controls that provide their own container can use FeathersTextInputBare.

[viridia]

A few things:

First, the term I have heard used for the little icons embedded in the text input widget (like "search", "clear" and so on) is "adornments".

However, the bigger concern is access to the buffer. Using the text input requires that the user have some means to directly access the EditableText component, which is going to be difficult if this is buried in the child hierarchy. Worse, the #Name feature of BSN only works in a single BSN scope, so there's no mechanism to export the entity id of the inner entity to outside callers. Instead, users will have to traverse the widget's internal structure to find the appropriate child entity in order to update the text, something I kind of wanted to avoid.

(Note that for the number input widget, this is not an issue, since the number input only exposes the numeric value, and doesn't permit updating of the buffer).

Both FeathersTextInput and FeathersNumberInput introduce a new problem which none of the previous widgets have had to deal with: every other widget, even ones with multiple entities (like slider) have an API surface such that users never have to interact with any entity other than the widget's root entity (sort of like the HTML "shadow DOM" concept - widgets have an internal DOM which is inaccessible from the outside). And the number input has been carefully crafted to make this true, so for example you can set a new numeric value at the top level, and the observers will detect this and update the internal text buffer accordingly. This is easy to do since the number input's state is tiny - just an enum containing a number.

So, if we made this change, then text input would now be the one widget that no longer follows this rule.

[0xEgao]

A few things:

First, the term I have heard used for the little icons embedded in the text input widget (like "search", "clear" and so on) is "adornments".

However, the bigger concern is access to the buffer. Using the text input requires that the user have some means to directly access the EditableText component, which is going to be difficult if this is buried in the child hierarchy. Worse, the #Name feature of BSN only works in a single BSN scope, so there's no mechanism to export the entity id of the inner entity to outside callers. Instead, users will have to traverse the widget's internal structure to find the appropriate child entity in order to update the text, something I kind of wanted to avoid.

(Note that for the number input widget, this is not an issue, since the number input only exposes the numeric value, and doesn't permit updating of the buffer).

Both FeathersTextInput and FeathersNumberInput introduce a new problem which none of the previous widgets have had to deal with: every other widget, even ones with multiple entities (like slider) have an API surface such that users never have to interact with any entity other than the widget's root entity (sort of like the HTML "shadow DOM" concept - widgets have an internal DOM which is inaccessible from the outside). And the number input has been carefully crafted to make this true, so for example you can set a new numeric value at the top level, and the observers will detect this and update the internal text buffer accordingly. This is easy to do since the number input's state is tiny - just an enum containing a number.

So, if we made this change, then text input would now be the one widget that no longer follows this rule.

Good point. I will rename the embedded controls to leading and trailing “adornments” and will rework on the value API so callers no longer need access to the internal EditableText entity. I am planning to expose TextInputValue on the FeathersTextInput root so inserting it updates the internal buffer, while user edits synchronize the value back and emit ValueChange<String> from the root. I’ll also make the inner editable entity crate-private and update the gallery to use only the root-level API.