I've mostly caught up on the (lively) discussion surrounding this
feature request.
It is clear that we do not yet have general agreement on the direction
this proposal should take, so let's continue to discuss the proposal,
its shortcomings, and any alternative approaches.
We should start by making sure that the motivation for doing this --
what problem is being solved -- is well understood. Andy will rework the
initial sections of the proposal to make it more clear.
If I can summarize what I see are the main concerns that have been raised:
* We should not make anything related to Behaviors public without a full
design of how Behaviors should work, what their responsibilities are,
how they interact with Skins
* This proposal doesn't solve the coupling of Skins and behaviors
* Function tags are defined in control class, but don't match the
functionality of control class
NOTE: this begs the question of whether there should always be a method
on control for each such function (even if the implementation just
delegates to the behavior
* An input map should not refer to the node and be stateless and
sharable among all (or some) instances of the same class; this would
mean mapping input events to Control::method rather than to
instance::method or to some arbitrary lambda
NOTE: this would depend on the previous being resolved
* Arbitrary key mapping seems out of scope for the core of JavaFX; this
sort of mapping could be done by the application if the event order
problem was solved, and if we had public API on control for all
functions that are called by the behavior.
* Should Input map be immutable?
* Changes to the Behavior system should focus on replacing complete
behaviors, and being able to use these by default for a certain subset
of controls (like -fx-skin provide in CSS)
There are probably other concerns as well.
Finally, one of the comments made, which I completely agree with, is
that API design needs to come first. It needs to be fully fleshed out,
and needs to be forward-looking. We should only expose as public API
what is needed to solve the problem and no more.
Let's continue the discussion with this in mind.
-- Kevin
On 9/29/2023 3:44 PM, Andy Goryachev wrote:
Dear fellow JavaFX developers:
For some time now, we’ve been working to identify missing features in
JavaFX that hinder application development. We’ve been working on
adding some of the missing features (for which we’ll have a separate
announcement), but I feel that engaging wider community is a rather
important part of the process.
I would like to share with you one such missing feature - ability to
extend behavior of the existing components (and make the task of
creating new components easier) by adding a public InputMap and
BehaviorBase.
Please find the actual proposal here
https://gist.github.com/andy-goryachev-oracle/294d8e4b3094fe16f8d55f6dd8b21c09
We are very much interested in your feedback. Thank you in advance.
-andy
