It's a bit odd though to move forward with a proposal that had no clear
consensus with developers on design and technical grounds first before
getting community feedback. I have not seen this with any of the other
JEP's published. Community feedback on this will need heavy filtering,
as with other JEP's, there will be plenty of uninformed opinions.
However I cannot imagine such feedback being useful on the level of API
design when the developers here already see several big design flaws. It
would be much more prudent to first iron those out before presenting
something that the developers here, who actually know the framework
better than most, already feel is an inadequate design.
So to me, yes, this still is simply trying a different route to get a
proposal through that was already deemed to need more design before it
can be accepted. Now however this proposal once presented as an
incubator feature will be pushed with uninformed and short-sighted
opinions that "just want a RichText control" completely ignoring
the tag-along InputMap part. One only needs to look in the bug tracker
or StackOverflow to see many of such opinions where there is a lack of
understanding of basic FX features, which are then used to justify some
new API or feature demand.
I also feel like it is ridiculous to tie a new **Control** to a new API,
as if it would be impossible to achieve otherwise. Any PR that exceeds
its scope in such fashion would normally be rejected, and told to be
split into multiple parts.
PR's should be kept small and focused to make them realistically
reviewable, being an incubator IMHO does not free you from passing
review. That means these must be broken up in pieces that can be
understood and reasoned about (like what happened to the Preferences API
for example). The RichText PR from what I can see it is making
sweeping changes in many areas unrelated to a new Control, and
with 40.000 lines, is one of the largest PR's ever. Such large PR's are
only acceptable if they are limited in scope, or are doing only fully
compatible changes (ie. clean ups, or refactoring of internals).
--John
On 05/11/2024 00:07, Kevin Rushforth wrote:
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.
