On Sat, 5 Oct 2024 18:19:31 GMT, Martin Fox <m...@openjdk.org> wrote:
> I said "think of how Shift+Right to extend the selection is implemented in > most table views". I never claimed it was handled by the scroll pane or even > that it should be. It is typically implemented by allowing an > event/action/selector/whatever to bubble up to the enclosing table view to be > acted on even if the focus lies on one of its descendants. I'm sorry, I misunderstood what you meant here. This kind of bubbling up is not the problem. Such events bubble up from the sub-structure of a control (say a table cell) to the table. The table is still the thing that has focus, which also manages a cursor (the active cell, or the more common cursor in an edit box). There is no confusion here for users what the focused control is and where input is going, and so it is absolutely fine to let this bubble up to a `Node` that is from a user perspective "focused" and part of the same control. This is not the case with `ScrollPane`. Here it clearly bubbles "out" of the focused area to a different control. If there was a focused box around the entire control (including the scroll bars, like a TableView, TextArea or ListView have) then it is clear to the user where input is going. > I was just countering this (new) concept that a control shouldn't act on a > keystroke unless it has direct focus. That's just not a generally accepted > rule. Perhaps I worded this poorly. What I always meant to say is a key press should go to the control that has visible focus. If that control is composed of (to the user irrelevant) other components, then it is fine to let events bubble up within the control and its substructure, as long as the event is not acted upon "outside" the user visible focused area. Acting on a key press bubbled up from a focused `Button` to a `ScrollPane` would clearly violate this. The scroll pane does not have visible focus, the button does. Acting on a key press bubbled up from a table cell doesn't violate this; the `TableView` has the focus (and shows this with a visual cue), the cell is just its cursor and is part of the table view's sub-structure. Here you can see that the `TableView` has the focused border, and so is free to act on key presses that bubble up to that point:  > If I understand you correctly you're once again citing a new rule, namely > that PgUp and PgDn shouldn't allow the focused node to scroll out of view. I'll admit that this just seems more like common sense than a rule... how else are you supposed to provide a UI that the user can intuitively grasp? You were talking about accessibility earlier, wouldn't an accessible UI also require that the control that has input focus is kept visible? > It is also not a generally accepted rule that if the default behavior isn't > correct in all cases it should be removed. It would definitely be hard to make that a general rule. It will have to be judged for each case if it does more harm than good. > I'm going to tap out of this conversation. I don't agree with these changes > but don't think they will inflict much harm. I believe that if there's > pushback from the developer community you will not get far using the novel > principles you're citing (like the one outlined in the bug title). But > perhaps I'm out of step on this and it's time for others to chime in. I understand, thanks for your feedback, it is appreciated and you brought several good points. Apologies if I sometimes word things poorly or come across a bit too invested in issues; I really do believe this is worth changing the current behavior for. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2395210869
