On Wed, 2 Oct 2024 21:12:07 GMT, Andy Goryachev <[email protected]> wrote:
> I played a bit more with your example. Your CustomButtonSkin is weird as it
> does not place the original button in the scene graph, not sure if that's
> important.
I think there is a misunderstanding. The `CustomButton` **is** part of the
scene graph (it's added by the user). It is after all the container in which
the Skin is placing the controls that give this custom control its appearance.
The easiest way to give it an appearance is to add a Text or Label, which I
did. Adding the Node provided to the Skin to the scene graph again (instead of
things like shapes, texts, labels, etc) would create a cycle (and FX wil throw
an immediate exception :-) )
The structure is:
CustomButton (situated in a container somewhere in the Scene, added by the
user to the scene graph)
|
--> Label (displaying the button text, added by the Skin)
The default skins work similar.
> I've added a number of custom components to the example
>
> ```
> static class L extends Label {
> public L(String s) {
> super(s);
> setFocusTraversable(true);
> setMouseTransparent(false);
> }
> }
> ```
>
> together with monitoring the scene's focusOwnerProperty (don't want to mess
> with CSS).
>
> These "L" components do traverse with the arrow keys and your fix with and
> without the ScrollPane. So perhaps I am wrong and we do want this change.
Yeah, without the fix these would also need to install navigational keys in
their input maps just in case someone made them focus traversable. It's a good
point that I didn't think of to justify this change, thanks for finding it.
> A couple of notes: the existing example, at least when considering its top
> two panels with the regular buttons, exhibits reduced accessibility when the
> scroll pane shows a scroll bar. One can still move focus and the scroll bar
> does scroll the focused component to view, but one cannot induce it to scroll
> (for example, if one adds a long label after the last button).
I also discovered the directional navigation seems to bug and skip controls if
you reduce the spacing in the HBox's to zero, but that's a separate problem for
sure.
> One can try making the scroll pane itself focusTraversable, but then the
> traversal becomes a bit weird. Perhaps it's a case for custom traversal
> policy.
I think it will be highly situational how an application would wish to handle
this. So, I'd say that a custom event handler for such keys, or perhaps indeed
something with traversal policies would need to be created by the user to solve
this on a case by case basis. It will be hard to always do the expected thing
with a control as generic as ScrollPane.
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1582#issuecomment-2391420435
