<Swing Dev> [Accessibility]Focus unable to traverse in the menubar

[Pavel Porvatov]

Hi Jing,
>
> Hello Anton,
>
>     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?
I'm not sure that javadoc changing is a good decision in this case. 
ContainerOrderFocusTraversalPolicy is designed for AWT, but I don't know 
why that policy cannot be used for Swing components as well. I see 
several problems:
1. We cannot change javadoc of ContainerOrderFocusTraversalPolicy 
because of backward compatibility
2. We cannot remove setFocusTraversalKeysEnabled(false) from the 
JMenuBar#JMenuBar() constructor because of backward compatibility

May be the best decision is to specify, that JMenuBar creates menu with 
the focusTraversalKeysEnabled = false

Regards, Pavel
>
> 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
>>>> etc.)
>>>> and so it can't be a member of a focus traversal chain. Swing's
>>>> default traversal policy (LayoutFocusTraversalPolicy) excludes
>>>> JMenuBar
>>>> 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)
>>>> method).
>>>>
>>>> Thanks,
>>>> Anton.
>>> Hi Anton,
>>> Thanks for reviewing the suggestion, and for your insights into this
>>> scenario.
>>>
>>> > From the Javadoc, it seems that setFocusTraversalKeysEnabled() is 
>>> mainly
>>> 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).
>>
>> Thanks,
>> Anton.
>>
>>
>>
>>
>>
>>
>