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

Reply via email to