Re: NSButtons and the Return key

[Fred Kiefer]

Looks like we all are in favour of Wolfgangs new behaviour. So let's
move to that.

Fred

Lars Sonchocky-Helldorf wrote:
> 
> Am 29.10.2008 um 19:07 schrieb Richard Frith-Macdonald:
> 
>>
>> On 29 Oct 2008, at 17:24, Wolfgang Lux wrote:
>>
>>> In response to my little rant about broken key view loops
>>> in the NSAlert and NSSavePanel classes in one of my yesterday's
>>> patches, Fred kindly pointed me to this message from the
>>> gnustep-dev mailing list:
>>> http://lists.gnu.org/archive/html/gnustep-dev/2007-02/msg00167.html
>>> In summary, Sergii proposed calling setRefusesFirstResponder:NO for
>>> the non-default buttons of an alert panel in order to prevent the
>>> user from selecting the wrong action accidentally by using the
>>> Tab button.
>>>
>>> I see the problem that Sergii wants solved here (and have indeed
>>> been bitten by it myself). However, I think that the real problem
>>> is that GNUstep's NSButtons fire their action upon pressing the
>>> Return key. IMHO, NSButtons should handle only the Space key and
>>> the Return key should always be sent to the default button (cell)
>>> of a window (if there is any at all). Then one could include all
>>> buttons in the key view loop with little risk of accidentally
>>> invoking the wrong action, but at the same time all buttons
>>> remain reachable via the keyboard for those that prefer it.
>>>
>>> Any opinions on that matter?
>>
>> I don't know whether it's a good idea or not, because I don't know how
>> MacOS-X does it.
> 
> Mac OS X does it like he said. You use the tab key to cycle the focus
> which is denoted by a thin blue ring around the element. The element
> which has the focus ring reacts on presses of the space bar (buttons get
> pressed, checkboxes toggle and NSPopUpButtons pop up) while the default
> button is solid blue and always reacts on presses of the return or enter
> key:
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
>>
>> IMO the 'right' way to do things is the way MacOS-X does them, so that
>> we don't get caught by incompatibilities and porting problems later
>> on.   At the very least, if we do things differently from MacOS-X we
>> will get people raising the difference as a bug report later.
>>
>> I don't say that's an absolute rule, but it's nearly so ... there
>> needs to be a very good reason for us to implement a behavior which
>> differs from the MacOS-X behavior (and where there is such a reason,
>> we should document the reason well).
>>
>> So my recommendation is to write a little test to see how MacOS-X does
>> it, then contribute the testcase to be added to the GNUstep testsuite
>> at the same time as any patch to implement the desired behavior.  That
>> way, not only do we get compatibility, we make sure that we keep
>> compatibility as long as we run the testsuite frequently enough to
>> show up any errors creeping in.