RFR: 8090456: Focus Management [v8]

[Andy Goryachev]

On Thu, 10 Oct 2024 22:48:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>>> I did my best to actually find some use cases...
>> 
>> Allow me to refer to some of the linked tickets in RFE https://bugs.openjdk.org/browse/JDK-8090456:
>> 
>> [JDK-8091524](https://bugs.openjdk.org/browse/JDK-8091524)
>> Introduce a "focus container" concept in class Parent
>> 
>> [JDK-8091670](https://bugs.openjdk.org/browse/JDK-8091670)
>> Add API for better control over keyboard focus
>
>> > I did my best to actually find some use cases...
>> 
>> Allow me to refer to some of the linked tickets in RFE https://bugs.openjdk.org/browse/JDK-8090456:
>> 
>> [JDK-8091524](https://bugs.openjdk.org/browse/JDK-8091524) Introduce a "focus container" concept in class Parent
>> 
>> [JDK-8091670](https://bugs.openjdk.org/browse/JDK-8091670) Add API for better control over keyboard focus
> 
> **JDK-8091524** - problem: User wants to create a panel that has its own focus cycle, and focus should not escape to other controls in the same Scene.  I saw this issue and feel that it is a "WON'T FIX" as there are standard solutions for this already.
> 
> It is clearly an X/Y problem.  A common thing that trips up beginning FX developers is that they're unwilling to create a 2nd Scene or a Dialog and prefer to just "add a child somewhere to show some extra controls".  This is not how you do this, and we shouldn't need to cater to something that is basically building a Dialog type infrastructure from scratch.  How would this handle mouse clicks outside the "blessed" panel?  Should that be restricted as well then?
> 
> Possible ways to address this problem: use dialogs, use nested event loops, disable components that should not be part of the focus cycle temporarily, overlay a transparent pane blocking clicks, etc... but best option, just use a dialog...
> 
> **JDK-8091670** - describes the same problem... Ensemble is not using the right tools to restrict focus.  Use dialogs for this purpose.  There is no need to restrict focus on container level.  Again, what happens when focus is restricted to a container, and the user clicks outside it?  What should then happen when I navigate?  Should the restricted container be part of the primary focus cycle, but then capture it with no way to exit it once you get there?
> 
> ## Working example
> 
> Just to show you can easily do this already, below is an example that will show a new pane, with navigation restricted to it, allowing you to select a new name for a button.  Note that you can't click outside it with the mouse (although I'm sure I can add that as well and then "hide" the dialog).  Also note that the Dialog doesn't appear as a dialog (they don't have to) and that no new Window is created on the task bar or whatever.
> 
> 
> package app;
> 
> import javafx.application.Application;
> import javafx.event.ActionEvent;
> import javafx.geometry.Point2D;
> import javafx.scene.Scene;
> import javafx.scene.control.Button;
> import javafx.scene.control.Dialog;
> import javafx....

@hjohn , thank you for the effort digging the tickets and preparing the examples!

At the same time, suggesting to use a bunch of event handlers seems less optimal to me.

On top of that, at least `four` people (JDK-8090456, JDK-8091670, JDK-8091524, and me) are asking for focus traversal policy in JBS and countless others on SO:

https://www.google.com/search?q=site%3Astackoverflow.com+%22javafx%22+%22focus+traversal%22&rlz=1C5GCEA_enUS1028US1030&oq=site%3Astackoverflow.com+%22javafx%22+%22focus+traversal%22&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIGCAEQRRg60gEJMTQzMTBqMGo3qAIAsAIA&sourceid=chrome&ie=UTF-8

I don't think we need to reinvent the wheel here.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2406191012