On Thu, 17 Jul 2025 05:18:28 GMT, Michael Strauß <mstra...@openjdk.org> wrote:
>> Implementation of [focus >> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29). > > Michael Strauß has updated the pull request incrementally with one additional > commit since the last revision: > > Avoid variable reassignment > _Mailing list message from [Andy Goryachev](mailto:andy.goryac...@oracle.com) > on [openjfx-dev](mailto:openjfx-...@mail.openjdk.org):_ > > My Swing is a bit rusty now, but I think it managed to handle geometry-based > navigation just fine. But it is not the reason I refer to Swing's > FocusTraversalPolicy. > > The application requirements might call for traversal that is governed not > only by geometry, but also by the state of the UI in general, even dynamic, > based on the information already entered by the user (as in "skip to item 25 > if you answered "no" here). This can easily be handled by disabling the controls that are not relevant when "no" was answered. This can be done dynamically and something that most UI's have been doing already since UI's were invented (I remember doing this in the early 90's). This is not a good enough reason to offer an alternative (and not complimentary) focus traversal mechanism. If for some reason those controls must remain "enabled", you can instead of disabling them remove their focus traversable flag -- note that you're actively confusing the user then though. > The value of the Parent.traversalPolicy is not only that it helps with > composite controls and skins, but also that it enables the application > developers to implement whatever crazy requirements they might have. FX shouldn't cater to crazy requirements; for inclusion in FX, this must be a **common** requirement, while offering sufficient power for "crazy" requirements. FX makes the common cases easy (I rarely find fault with FX's default focus traversal), and there's more than sufficient controls available to support more exotic requirements. > Also, the FocusTraversalPolicy (whatever form it eventually might take) is > not a foreign concept transplanted from an older system. JavaFX, in fact, > already has these policies internally implemented, offering a small, but > important benefit of not altering the behavior of the existing code. Yes, and almost universally when I encounter its usage in the behavior/skins, they actually show a lack of understanding of how FX works, or are no longer relevant as FX evolved. I'm very sure we can remove the entire internal system (think of how much code that would safe, and how similar the user model then becomes for their own skins) and not lose any functionality by just using what FX offers with regards to focus traversal. One of the biggest stumbling blocks for this has been removed already (see #1582 ). As you didn't share any use cases that are even remotely common, it is still hard for me to imagine why we need an alternative navigation system when JavaFX's system out-of-the-box was by default 10x better than what Swing offered before it introduced the focus traversal policy. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3146464405
