Hi, Shashi.
I checked it on the fresh build of jdk/client, and confirm that it is possible
to select progress bar using ctrl+option+up/down/left.
Screenshot is attached to the bug.
On 04/11/2018 23:08, shashidhara.veerabhadra...@oracle.com wrote:
Hi Sergey, I enabled 'All controls' access in the
'Keyboard->Shortcuts->Accessibility' but still was not able to get the focus
unto the progress bar and even with the short cut that you mentioned it always
skipped the progress bar. The control would move from 'edit text box' to 'Start
loading text' button. Even the bug description says to use the tab key to do this
operation.
Only with this fix, I was able to select the progress bar control and otherwise
not and that is true as per the focus traversal policy used for this control
type.
Thanks and regards,
Shashi
On 03/11/18 3:00 AM, Sergey Bylokhov wrote:
I am not sure that the focusable property should be changed to fix this issue.
because the property is ignored when a11y shortcuts are used, at least I am
able to select the progress bar using ctr+shift+cnd+left/right/up/down. And
VO reads the current value of the progress bar, but if the demo is in
progress("Start
loading text" button was pressed) the VO did not read information about the new
values of the progress bar.
On 24/10/2018 22:31, Shashidhara Veerabhadraiah wrote:
Hi Sergey, While fixing this bug I did not verified the behavior of other
components and how they behave with respect to the AT. Since the question about
other components came up and did some debugging on that part. Below is the
reason that I could find:
It is all about the focus traversal policy that is used for each component
type. While the both the JProgressBar and JLabel derived from JComponent and
then JComponent is also derived from Container and Component class.
JProgressBar component goes via the DefaultFocusTraversalPolicy(.java) while
the JLabel goes via the ContainerOrderFocusTraversalPolicy(.java) where there
are overriding methods of accept() function. This builds different behavior for
JLabel and JProressBar while focus traversal.
Since the both the components are derived out of Component class both are
default to focusable to true(Component.java) but because of the way accept()
method is overridden, JProgressBar's focusable state is considered only when
the focus traversable is overridden(not FOCUS_TRAVERSABLE_DEFAULT). Now by
calling setFocusable() explicitly overrides the current policy to
FOCUS_TRAVERSABLE_SET, hence the focusable state of the JProgressBar is
considered afterwards.
Hope this answers. Please let me know if you have any questions.
Thanks and regards,
Shashi
-----Original Message-----
From: Sergey Bylokhov
Sent: Thursday, October 25, 2018 3:11 AM
To: Shashidhara Veerabhadraiah <shashidhara.veerabhadra...@oracle.com>;
awt-...@openjdk.java.net; swing-dev@openjdk.java.net
Subject: Re: <Swing Dev> [12] JDK-7124285: Nothing heard from VoiceOver
regarding the status of the progress bar
Hi, Shashi.
Can you please provide more information about relation of focusable state and a
VoiceOver? The simple JLabel is not focusable, but VoiceOver reads its
contents, and it is possible to select the label using VoiceOver's shortcuts.
On 22/10/2018 00:36, shashidhara.veerabhadra...@oracle.com wrote:
Hi All, Please review a swingset fix for the below bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-7124285
Fix: http://cr.openjdk.java.net/~sveerabhadra/7124285/webrev.00/
Problem: The JProgressBar component used in the swingset demo was not focusable
and once it is turned on, now the progress status is getting narrated via the
voice over.
Thanks and regards,
Shashi
--
Best regards, Sergey.
