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. I'm very sorry Andy, but most of these are just **asking** for X thinking it will achieve their goals, based on how things work in other frameworks (like in AWT focus traversal policy) or how they saw how things worked internally (TraversalEngine). That does not mean that X is the solution. This is why you need to analyze this and see what the real need for this is, and then create something that fits well, or make easier to use something that exists already. In other words, use cases, which I still have not seen; the only thing I have seen is user reports that say they want X without describing what they want to achieve, examples: |SO|Analysis| |---|---| |https://stackoverflow.com/questions/15238928/javafx-how-to-change-the-focus-traversal-policy|Asks for X, doesn't describe why they need it| |https://stackoverflow.com/questions/38681768/how-focus-travel-in-javafx|They added the fields in the wrong order in the GridPane; giving them traversal policies to fix this will only complicate what is just simple re-ordering of children| |https://stackoverflow.com/questions/51326353/how-to-properly-handle-focus-of-children-in-javafx|Wants to focus a pane with mouse, needs to set MouseTransparent to false| |https://stackoverflow.com/questions/25431959/is-there-a-way-to-take-away-focus-in-javafx|May benefit from focusNext/Previous type methods| |https://stackoverflow.com/questions/29984025/focus-on-next-item-in-container|Needs focusNext/Previous type methods| |https://stackoverflow.com/questions/25254769/javafx-how-to-manage-the-focus-traversal-in-a-borderpane|Non-issue, navigation already worked correctly| |https://stackoverflow.com/questions/20834472/javafx-8-0-how-to-change-the-focus-traversal-key|Won't be solved by this PR| |https://stackoverflow.com/questions/19625218/javafx-scrolling-vs-focus-traversal-with-arrow-keys|Would benefit from ScrollPane not consuming bubbled up arrow keys| I can go on, but I'm unsure why I need to. This analysis and the use cases should already be there as they're input for the API design. You say a "bunch of event handlers" is less optimal; then optimize that. It's already there. In fact, a simple utility makes it a one-liner... ------------- PR Comment: https://git.openjdk.org/jfx/pull/1555#issuecomment-2406217617
