Re: NSButtons and the Return key

[Lars Sonchocky-Helldorf]

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.
>
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep