JDK-8091673 : Public focus traversal API for use in custom controls
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: fx2.0.1,fx2.0.2
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-02-02
  • Updated: 2024-11-16
  • Resolved: 2024-11-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
jfx24 b17Fixed
Related Reports
CSR :  
JDK-8342906 - Public focus traversal API for use in custom controls
Duplicate :  
JDK-8090501 - Promote setImpl_traversalEngine to public API
Relates :  
JDK-8090456 - Focus Management
Relates :  
JDK-8092194 - ☂ Improve support for building custom UI controls
Description
A custom direct Control subclass cannot cause focus to leave itself without delegating to a non-published class or method.

There is Node#impl_traverse(Direction) but the method is explicitly excluded from the public API and the Direction type is in a non-published package.

BehaviorBase<C,S> cannot be used as it is also in a non-published package.

Further, there is no published abstract base class of type Control supporting keyboard focus traversal behavior.
Comments
Changeset: 688f7fa0 Branch: master Author: Andy Goryachev <angorya@openjdk.org> Date: 2024-11-12 23:48:31 +0000 URL: https://git.openjdk.org/jfx/commit/688f7fa0168143c9c73dd8f17cbe668f9d19f79c
12-11-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jfx/pull/1628 Date: 2024-11-06 17:49:59 +0000
06-11-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jfx/pull/1604 Date: 2024-10-18 19:20:05 +0000
22-10-2024
Updated webrev here: http://cr.openjdk.java.net/~jgiles/8091673.1/ The primary changes are: removal of ParentTraversalEngine (now TraversalEngine is the primary class), and renaming of 'select*' methods to instead be 'find*'.
02-08-2017
Thanks :-)
12-04-2017
+1 nice :-)
12-04-2017
A revised proposal for focus traversal is now available for review at the following URL: http://cr.openjdk.java.net/~jgiles/8061673/ A first pass as javadoc documentation has been completed on the public API, but a second pass is anticipated once the API is reviewed and discussed in more depth. The main requirements were handled as follows: 1) The ability to request traversal from a node is handled by Node#traverse(TraversalDirection) 2) The ability to change the traversal algorithm used by some subsection of the scenegraph is possible through Parent#traversalEngineProperty 3) The ability to listen to traversal events is removed from the TraversalEngine API, and a new TraversalEvent type is introduced, making use of the standard JavaFX event system. There is some discussion that should occur around the method naming - the use of 'select*' in particular, as to me it feels like this is misleading as the selection is literally only finding the appropriate node, where some might expect it to also result in focus moving. A better name shouldn't be hard to find.
12-04-2017
Email from Martin for consideration when time allows: ---------------------- Hi Jonathan, just a few thoughts about the API. When I was adding some of the functionality to traversal, I could not touch the public API. All we had there was the impl_ method for adding TraversalEngine. This means there is some functionality that IMO should have been directly in the scenegraph. First of all, the TraversalEngine serves for 2 different purposes: 1) overriding traversal algorithm for the given subtree 2) adding listener to the subtree. I think only the #1 should be really part of the TraversalEngine. It would be better to register listeners directly on the scene/parent. This would simplify the code as currently there are engines that are really just a containers for listeners and they need to be special-cased. The setOverriddenFocusTraversability/ isParentTraversable is there just for Toggle button traversability ( RT-36659). I don't think this should be part of the public API. This basically switches off the traversability of unselected nodes that are part of a Toggle group, so that only the selected one can be traversed to. The ParentTraversalEngine is misused there just mark the node has overridden traversability. I'm not sure how to replace it though. Too bad that Toggle/ToggleGroup is in control and traversal engine does not know about it, so it cannot check for it. This might be possibly marked by a property (?) directly on the node? It would be kind-of a property intended to be used by controls and not by the user, as the user already has his ways to control the focus. Anybody has a better idea here? Also, TopMostTraversalEngine probably shouldn't be exposed, unless there's public Scene property for it. This would allow to change the default algorithm for the Scene (one that can be then accessed in TraversalContext). The constructor for this is missing (still package-private) however. If you want this functionality, you should probably publish also (Sub)SceneTraversalEngine. If not, TopMostTraversalEngine is useless and may stay in the private API space. Cheers, -Martin
06-10-2015
JavaDoc of proposed new javafx.scene.traversal package is available here: http://jonathangiles.net/javafx/jdk9/traversal/ What is not noted in this JavaDoc is the changes to API in Node and Parent classes.
16-09-2015
Attaching proposed patch that would do this. Note that it has not been reviewed in terms of JavaDoc.
15-09-2015
FocusModel is only for internal focus traversal of controls such as ListView, TreeView and TableView. Reassigning to Mick who is in charge of global focus traversal.
02-02-2012
Reassigning for evaluation to Jonathan who is the author of FocusModel.
02-02-2012
This is required for the case where a custom Skin<C> is implemented using a Node that has no built-in keyboard event handling. e.g., a skin whose root node is a StackPane or a Region. The KeyEvent handler developed for that control has no safe way to implement the expected TAB and SHIFT-TAB behavior.
02-02-2012