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

Jing Lv lvjing at linux.vnet.ibm.com
Thu Dec 8 08:54:11 UTC 2011


Hello,

     Thanks Pavel. Some update from the developers. One question remains 
that given menus or menubars are supposed to be added to the main 
container rather than mixing them with the other components in the UI,  
why the JMenuBars are made focus enabled by default when their focus 
traversal keys are disabled. If someone moves the focus to the JMenuBar, 
how would they move the focus away from the JMenuBar if the focus 
traversal keys are disabled (So does JMenuBar really needed to be focus 
enabled by default)? Shall we also modify the spec/implementation to 
make it clear to the customers?
     Thanks.

On 2011/11/9 19:25, Pavel Porvatov wrote:
> Hi Jing,
>> Thanks Pavel,
>>
>>      It seems fine to me, if no other suggestions/opinions, I guess 
>> we can move on with this?
> Yes, we can. Could you please file a bug for the problem as well?
>
> Thanks, Pavel
>>
>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>




More information about the swing-dev mailing list