<Swing Dev> [Accessibility]Focus unable to traverse in the menubar
lvjing at linux.vnet.ibm.com
Tue Nov 1 23:39:15 PDT 2011
Thanks for the review. I am still trying to figure out some real
case and provide more detail the customer may fail.
Anyway, I agree we'd better update the java spec to make it clear
for the customers. I'd like to know if anyone can help with that?
On 2011/10/12 20:54, Anton Tarasov wrote:
> Hi Neil,
> On 10/10/2011 7:01 PM, Neil Richards wrote:
>> On Mon, 2011-10-10 at 16:56 +0400, Anton Tarasov wrote:
>>> Hi Neil and Jing,
>>> I'm afraid that it's wrong to use ContainerOrderFocusTraversalPolicy
>>> for swing components. This policy is designed for AWT.
>>> JMenuBar calls setFocusTraversalKeysEnabled(false) in its ctor which
>>> means that it "swallows" focus traversal keys (like TAB/SHIFT-TAB
>>> and so it can't be a member of a focus traversal chain. Swing's
>>> default traversal policy (LayoutFocusTraversalPolicy) excludes
>>> from a focus traversal cycle. ContainerOrderFocusTraversalPolicy is
>>> not "aware" about JMenuBar and so it allows it.
>>> So, either a default Swing policy should be used, or a custom policy.
>>> At worst, ContainerOrderFocusTraversalPolicy should be overriden
>>> to exclude JMenuBar from a cycle (override its accept(Component)
>> Hi Anton,
>> Thanks for reviewing the suggestion, and for your insights into this
>> > From the Javadoc, it seems that setFocusTraversalKeysEnabled() is
>> concerned with choosing whether focus traversal key presses (normally
>> TAB and SHIFT-TAB) are processed "automatically" (when 'true') or are
>> delivered to the Component as key events (for the component's code to
>> process "manually").
>> (In the case of JMenuBar, it makes them come through as key events, but
>> doesn't do anything special to process these events, which is why they
>> get discarded.)
> That is right, though it doesn't directly relate to the issue we're
> talking about =)
>> Your description above, though, seems to suggest that it is generally
>> undesirable for the JMenuBar to be given the focus, as all the
>> Swing-aware focus traversal policies make a point of not giving focus to
>> JMenuBar items.
>> If this is so, then wouldn't it make sense to call setFocusable(false)
>> from its constructor (too), to ensure it doesn't get focus ?
>> Or, to put it another way, could you explain a little of the reasoning
>> or scenario behind why it is desirable for JMenuBar items to be
>> generally focusable, even though they aren't focus-traversable ?
>> I think such an explanation would be really helpful in clearing up my
>> confusion on this point.
>> Thanks, Neil
> Well, I suspect that the core of the problem is that adding JMenuBar
> as JComponent to a swing
> container doesn't make much sense. Though it is not directly
> prohibited, doing so may cause
> side effects like the one you've discovered. When JMenuBar is set
> properly onto a JFrame its focus
> is managed by JRootPane and its focusability just isn't taken into
> account. That's may be the reason
> it's not declared unfocusable. Honestly, I can't tell you exactly.
> If you do it, you probably won't make any harm, but I personally don't
> think this is a vital fix
> (unless you have a good use case of the scenario you've provided).
> Anyway, this is a swing question
> (I'm, as an AWT dev member, leaving the decision to swing guys).
More information about the swing-dev