RFR: 8340852: ScrollPane should not consume navigation keys when it doesn't have direct focus
John Hendrikx
jhendrikx at openjdk.org
Wed Oct 2 02:27:41 UTC 2024
On Tue, 1 Oct 2024 19:50:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:
> > Here is a minimal working example
>
> Very helpful, thank you.
>
> I would say the use of arrow keys to traverse focus in this case _looks to me_ to be application-specific. In other words, this may or may not be the desired behavior.
>
> In the context of a simple dialog which only has buttons - yes, it `is` the desired behavior. In the case of a more complex UI where text input components are present - probably not, but it may depend on the application requirements.
I am sorry, you're saying that you think it is okay that setting a Skin suddenly makes your control malfunction, but only if it has a `ScrollPane` somewhere in its hierarchy? Where is the logic exactly? Should it not be either:
- All navigation stops working for custom controls, regardless of placement
- Navigation keeps working for custom controls, regardless of placement
... this in between stance is baffling me, and seems to be just defending the status quo in favor of a work-around solution that is not addressing core problems.
The fact that I used buttons has no bearing on this. Other controls will have the exact same problems, if they let directional keys bubble up. For text input controls this is usually not the case as they have other purposes for those keys, but that may change with read only status, or if they want to say allow scrolling from one text component to the next.
> In your example, the navigation with TAB / shift+TAB is there, and it works correctly in all four panes. So it's not like the functionality is severely impeded.
Yes, I never claimed tab didn't work. I only claimed that FX is duplicating navigation everywhere in its own controls, just so users wouldn't have to deal with ScrollPane affecting navigation keys.
It sounds like you would be okay with having FX controls behave in the same way, then at least it would be consistent. So let's remove directional navigation from all FX controls, and only have that bubble up to Scene when there is no ScrollPane in between. Then custom controls and FX controls would be on the same footing.
Or, alternatively, let's remove default navigation from Scene and make navigation not a global concern (as it should really be) but the business of each and every control built..
> What I am saying is that what we currently have is probably ok and JDK-8340852 may not be needed.
I'm unable to follow your reasoning. If you could explain in more detail why you think the current system should:
a) Have navigation decentralized in every control
b) Should lose only half of the standard navigation keys (not all, or none) when a Skin is assigned
c) Custom skinned controls have different navigation when placed in ScrollPane while FX controls don't
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2387509660
More information about the openjfx-dev
mailing list