<Swing Dev> [9] Review request for 8074883: Tab key should move to focused button in a button group

[Sergey Bylokhov]

On 02.11.16 10:51, Semyon Sadetsky wrote:
> On 11/1/2016 10:37 PM, Sergey Bylokhov wrote:
>
>> On 28.10.16 11:20, Semyon Sadetsky wrote:
>>>> probably it is possible to change the while loop to something? just to
>>>> hide the usage of Enumeration? like
>>>> Enumiration.asIterator().forEachRemaining()?
>>> I did not get why. What is wrong with Enumeration?
>>
>> It is an old style iterator, and we can hide its usage.
> Okay. http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.02/

But what about the question to specification, is it the spac below is 
true when the selected toggle button is disabled?:

48 * If this toggle button is a member of the {@link ButtonGroup} which 
has an another focusable toggle button selected, and the focus cause 
argument denotes window activation or focus traversal action of any 
direction the result of the method execution is the same as calling 
{@link Component#requestFocus(FocusEvent.Cause)} on the toggle button 
selected in the group.

Because the current implementation filter out disabled components(the 
same question is about invisible, non-displayable), but according to the 
spec results should be the same like we call the method directly on the 
selected button.

>>
>>>>
>>> If a component is disabled it cannot receive input focus, see
>>> java.awt.Component#isEnabled specs.  The proposed spec clearly states :
>>>
>>>  247      * If this toggle button is a member of the {@link ButtonGroup}
>>> which has
>>>  248      * an another ***focusable*** toggle button selected, and the
>>> focus cause argument
>>>
>>>> It seems that the code in getGroupSelection() will focus the first
>>>> element in the group, but what elements will be focused if we call
>>>> Component#requestFocus(FocusEvent.Cause) directly for this disabled
>>>> compoenent? Will the the same(first) element be selected?
>>> I did find any mentions of "first element" in the proposed spec. Please
>>> clarify this question.
>>> According to the proposed spec the case when
>>> Component#requestFocus(FocusEvent.Cause) is called on disabled component
>>> will be handled as:
>>>
>>>  253      * In all other cases the result of the method is the same as
>>> calling
>>>  254      * {@link Component#requestFocus(FocusEvent.Cause)} on this
>>> toggle button.
>>
>> The specification states that the call to
>> this.requestFocus(FocusEvent.Cause cause);
>> and the call to
>> selected.requestFocus(FocusEvent.Cause cause);
>> produce the same result "If this toggle button is a member of the
>> {@link ButtonGroup} which has an another focusable toggle button
>> selected, and the focus cause argument denotes window activation or
>> focus traversal action of any direction"
>>
>> The question was "is that always true if the selected element is
>> disabled(but focusable)"? I guess that the implementation in the fix
>> will select the first "this"(the button on which requestFocus() was
>> called), but in the second case something different will be selected.
>>
>>>>> On 10/25/2016 3:14 PM, Alexandr Scherbatiy wrote:
>>>>>> On 10/19/2016 8:14 PM, Semyon Sadetsky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review fix for JDK9:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8074883
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8074883/webrev.00/
>>>>>>>
>>>>>>> To avoid unexpected selection change the selected button of a button
>>>>>>> group should always grab focus when focus is transferred form
>>>>>>> component outside the group to any unselected button inside the
>>>>>>> group
>>>>>>> in case of traversal or initial container activation actions.
>>>>>>   - It is better to pass the cause and boolean focusInWindow
>>>>>> arguments
>>>>>> to the getGroupSelection() method to avoid some code duplication like
>>>>>> switching over the same cause values.
>>>>>>   - The fix will require a CCC request because it updates a javadoc
>>>>>> for the publci method.
>>>>>>
>>>>>>   Thanks,
>>>>>>   Alexandr.
>>>>>>>
>>>>>>> --Semyon
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.