On Tue, 1 Oct 2024 19:50:44 GMT, Andy Goryachev <ango...@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

Reply via email to