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

[Jing Lv]

Thanks Pavel,

      It seems fine to me, if no other suggestions/opinions, I guess we 
can move on with this?

On 2011/11/2 19:58, Pavel Porvatov wrote:
> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>