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). 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. 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. -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx <jhendr...@openjdk.org> Date: Wednesday, July 30, 2025 at 18:54 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: RFR: 8343956: Focus delegation API [v3] On Thu, 31 Jul 2025 01:20:06 GMT, Michael Strauß <mstra...@openjdk.org> wrote: > _Mailing list message from [Andy Goryachev](mailto:andy.goryac...@oracle.com) > on [openjfx-dev](mailto:openjfx-...@mail.openjdk.org):_ > > I think I narrowed down my objection to this proposal. My main problem with > it is that it tries to add properties to the wrong entity (Node). > > In a typical application, the focus traversal requirements usually come in > the context of a higher level aggregate such as a form, or a panel, or a > window, and not the individual nodes. An example from Swing and AWT is the > FocusTraversalPolicy class. This is no accident - the focus traversal might > be dynamically dependent on other aspects of the UI state, for example the > kind of information already present in a form. The reason Swing has a FocusTraversalPolicy is because its layout system is decoupled from focus traversal. Layout managers in Swing determine the positions of components but do not expose any information about a good traversal order of those components. As a result, the container has no built-in understanding of how focus should move between components based on layout. So Swing needed a FocusTraversalPolicy because layout managers (although flexible) do not provide any inherent information on focus traversal order. In contrast, JavaFX integrate layout and focus order more tightly through hierarchical scene graphs, node ordering, and orientation (for some controls). In other words, there is more than enough ways to influence focus traversal order: - Making logical groups which comes naturally with the various containers - Adding nodes to containers in the desired focus order - Leveraging disabled, visible, and focusTraversable properties for even more control For instance, if a GridPane should traverse top-to-bottom rather than left-to-right, it’s simply a matter of adding the nodes in top-down order. JavaFX respects the order in which nodes are added, regardless of their visual grid positions. So, I don't think grabbing this idea from Swing and adding it to FX can ever be the right solution as it was introduced there to solve a completely different problem (not using order of children + layout managers being decoupled and unable to confer focus traversal information). If there are currently problems with FX's focus traversal order that can't easily be solved by using the existing tools (especially node order), that are common problems for users, then please share these, and let's see how these concerns can be addressed by enhancing what is already there instead of overriding it. Perhaps a `Node.setViewOrder` type mechanism is needed, but for focus -- but I struggle to think why this couldn't be solved by simply moving the child in the correct position... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3138313755
