The goal of incubating these or any other APIs is to get feedback from
applications developers as they use them, and be able to react to that
feedback with the freedom of being able to make incompatible changes. If
and when a feature is generally accepted, and we think the API is ready,
we would then propose finalizing it.
I'll reply to the questions raised about RichTextArea and InputMap
separately, with a new subject line, to decouple it from the discussion
of incubator modules in general.
-- Kevin
On 11/3/2024 7:46 AM, John Hendrikx wrote:
I can only second this. I haven't looked at the RichTextArea, but
find it extremely odd to hear that it also includes part of the input
map proposal instead of just a new Control/Skin/Behavior. Any changes
to how input maps work should be a separate proposal and PR.
--John
On 02/11/2024 00:19, 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.
