John,
Thank you for continuing this discussion. This particular response might need
its own thread and a topic (FocusTraversalPolicy).
I want to emphasize that JavaFX should provide support for "crazy" as you put
it requirements. In my experience, the world of enterprise software is full of
"crazy" requirements that have solid business justification. I already
presented a use case ("skip to item 25 if you answered no here"), and it cannot
/ should not be implemented by disabling the control, as the input fields still
need to be editable.
And no, there are always use cases that the stock JavaFX implementation cannot
support and the application developers need a way to implement then, preferably
via some easy-to-understand API. The FocusTraversalPolicy is one such API that
solves the problems of skin and application developers nicely, with an easy to
understand API. Providing a geometry-based focus traversal (and the other
usual navigation schemes) **may not be enough**. The real world requirements
are more complicated that any JavaFX developer, even the smartest ones, can
imagine.
-andy
P.S. I realized that my example may be not entirely clear if one has not
encountered such scenarios before. I'll try to provide a more clear one in a
separate thread.
From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx
<jhendr...@openjdk.org>
Date: Saturday, August 2, 2025 at 05:10
To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org>
Subject: Re: RFR: 8343956: Focus delegation API [v3]
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
