Cleaned up the Focus Traversal Policy proposal a bit, see https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversalPolicy.md .
My problem with the Focus Delegation proposal is that it tries, as you put it, to span different levels of abstraction, in my view, unnecessarily. Node already has the focused/focusWithin properties that are sufficient. There is more: I think the kind of issues we see stem from the sub-optimal event dispatching mechanism in JavaFX, the weirdest part of which is creating multiple event instances for the same event. The key events should be targeting the keyboard focus owner, in case of the Spinner and similar controls, the TextField inside of it. "Control" and "Skin" are abstractions that have nothing to do with that, and the Spinner itself might conceptually be a part of some other custom control. To answer the last two points: 1. the leaf TextField should be the focused Node, not its parent Control, or its more complex custom control. 2. to avoid duplicate events, don't duplicate events. I hope to continue this conversation, since we all have one goal in mind - to make JavaFX better. -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß <mstra...@openjdk.org> Date: Wednesday, July 30, 2025 at 18:23 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):_ > > 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. > > Trying to implement it at the Node level would be extremely difficult, and > one will inevitably resolve to creating a kind of controller that determines > the traversal order at the higher level. > > A better approach, in my opinion, would be to revive the FocusTraversalPolicy > API [0], [1] (after some modernization). The most important feature that > would be added is enabling ability to plug in a custom traversal policy that > can address any application-level requirements with relative ease. I don't think that these two proposals are at odds, in fact they are completely orthogonal. Focus delegation has nothing to do with focus traversal. We're not trying to answer the question what happens when (or how) we move the input focus to another control. Focus delegation is an implementation of multi-level focus for composite controls. It spans different levels of abstraction, something that JavaFX already attempts to do right now, but fails due to a lack of supporting infrastructure. I don't see how a customizable focus traversal API addresses _any_ of the two major improvements that focus delegation brings to the table: 1. A consistent focus delegation chain: focusing a descendant control keeps the outer control focused, which is what would be expected in a black-box control model. 2. Events are not duplicated, they are logically consistent for all observers. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1632#issuecomment-3138275955