Dear John: Thank you for providing the alternative proposal. One thing I liked is the clarification of the purpose of behavior to translate input events into platform-independent actions.
I noticed you tried to validate the design using Button - a rather simple Control. I think a better choice would be to pick one of the more complex controls such as TableView or TextArea. Another missing piece is probably a set of behavior tests similar to https://bugs.openjdk.org/browse/JDK-8314906 to verify that the behavior does not change from the user perspective. One important problem I tried to solve is managing the key bindings. I think it’s an important functionality that needs to be provided, evident from the plethora of use cases described earlier in the discussion. I cannot see from the PR how you propose to address the issue, and the examples you mentioned earlier look to me more complicated than necessary. I have hard time understanding where the idea of static or singleton behavior comes from exactly, and what benefits it provides. The whole design overlooks the fact that behaviors are tightly coupled to skins - to the point where it gets progressively difficult to provide a reasonable skin-to-behavior interface when skins have a different design (in appearance and the kinds and number of nodes involved). Adding more events and have them bubble up the hierarchy is, in my opinion, a departure from the current design, possibly a source of regression, impacts performance (however slightly), and is completely unnecessary. The application developer can easily achieve that with existing mechanisms should such a function is indeed needed. Of course, I can be missing some important points altogether, and/or be completely wrong about what people want (tm). Now that Kevin is back from vacation, we could have an internal discussion of the two proposals to determine how we can move forward. Thanks again for a lively discussion and the PR. Cheers, -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx <john.hendr...@gmail.com> Date: Friday, October 20, 2023 at 14:40 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Proof of concept pull request for Behavior API (PR 1265) Hi list, I've made a proof of concept for possibly exposing Behaviors as a first class API in JavaFX. It's by no means complete, and there will be some significant hurdles still no doubt, but this proof of concept does replace the internal ButtonBehavior completely with a newly implemented public ButtonBehavior (and it seems to be all working still). The proof of concept shows the basics behind this proposal, and introduces a Behavior interface, a BehaviorContext interface, a public ButtonBehavior and a class with ButtonEvents. There is also an Alternate ButtonBehavior which (somewhat clumsily) changes the SPACE key for selecting a button to the "A" key. I suspect it shouldn't be too hard to make this a bit more streamlined. One thing of note that I haven't quite figured out yet; even though the new ButtonBehavior does not install the Navigation keys, Navigation still works; this is not because the old behavior is still active behind the scenes, but just seems to work out of the box. I'm hoping this will make the idea behind this proposal a bit easier to grasp. Note that I'm also mainly trying to make it possible to be able to remap keys, but I want to make sure that this is done in such a way that it doesn't block a future open sourcing of a Behavior API. With this proposal it's possible however that Behaviors must become public first though before being able to access the necessary classes to change input mappings. The PR can be found here: https://github.com/openjdk/jfx/pull/1265 Feel free to comment here or on the PR. The PR is in draft, so comments there will not show up on the mailing list. Note: the test failure is because tests are using reflection to access a behavior field that is part of skins; this field is no longer present for ButtonSkin. --John
