As noted, the current RichTextArea proposal depends on the InputMap
proposal. Andy will make this more clear by filing a new JBS Enhancement
(or reusing the existing one) for "InputMap (Incubator)", and adding
that issue to the RichTextArea PR.
The idea of incubating InputMap along with RichTextArea is to get
feedback on InputMap as an incubating feature with a concrete example
control that uses it, and would benefit by it. An alternative would have
been to incubate InputMap separately, although that would require
picking a simple control or two and creating a "test" version of that
control solely for the purpose of testing InputMap. I don't think it
would provide the kind of feedback we are looking for. Using it with a
control that we actually expect developers to use seems like a better
test of InputMap. It does tie the two proposals together, at least
during the time that they are incubating.
Given that RTA and InputMap are two distinct features, I can see three
likely outcomes after incubating for some number of releases, where we
gain feedback and iterate the design and API:
1. Both RTA and InputMap gain general acceptance among app developers --
in this case, both would be finalized at the same time in some future
release. This is what we are aiming for.
2. RTA gains general acceptance, but InputMap does not -- in this case,
RTA would need to be reworked to remove all dependencies on InputMap,
with some alternate customization of behavior that is specific to RTA,
which would then be finalized in some future release.
3. Neither RTA nor InputMap gain general acceptance -- in this case,
both would be removed in some future release.
-- Kevin
On 11/1/2024 4:19 PM, Michael Strauß wrote:
I think it should be made clear that incubation is not an alternative
to, or a path around community concensus. Specifically, I'm looking at
the RichTextArea proposal, which seems to also incubate the InputMap
proposal. If we accepted the incubation of incidental features without
community concensus, then surely at some point in the future, we'd be
discussing that we now must commit to a controversial incidental
feature because the momentum is too strong, or because we'd be
breaking code of too many users that are already using the new
features. Any discussion around promoting the main incubating feature
to API, and dropping incidental features will be tainted with
real-world usage arguments.
