On Thu, 10 Oct 2024 22:48:42 GMT, John Hendrikx <jhendr...@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
