Re: NSButtons and the Return key

[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.

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.