RFR: 8343956: Focus delegation API [v3]

[Andy Goryachev]

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-retn at openjdk.org> on behalf of John Hendrikx <jhendrikx at openjdk.org>
Date: Saturday, August 2, 2025 at 05:10
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: RFR: 8343956: Focus delegation API [v3]
On Thu, 17 Jul 2025 05:18:28 GMT, Michael Strauß <mstrauss at 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.goryachev at oracle.com) on [openjfx-dev](mailto:openjfx-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250804/35b29e5e/attachment.htm>