Re: KEYNAV:GtkEntry And Accessibility (bug 53763)

["Padraig O'Briain" <Padraig Obriain sun com>]

Calum,

Is resolving these points of contention something the GNOME usability group 
could or should be doing?

Padraig

> X-Accept-Language: en
> MIME-Version: 1.0
> To: "Padraig O'Briain" <Padraig Obriain sun com>
> CC: gnome-accessibility-list gnome org
> Subject: Re: KEYNAV:GtkEntry And Accessibility (bug 53763)
> Content-Transfer-Encoding: 7bit
> 
> Padraig O'Briain wrote:
> > 
> > By default, when a GtkEntry field has focus, Tab should insert a Tab
> > character, and Ctrl+Tab (or Shift+Ctrl+Tab) should navigate focus away from
> > that control.
> > 
> > <POB> This is not implemented. Is this a nice to have or a mandatory? </POB>
> 
> This is one of the two biggest points of contention left that we need
> some agreement on.  The options (as I see it) are either:
> 
> 1) Always have Tab insert a tab character, and Ctrl+Tab navigate out. 
> This is the current proposal, but it makes tab key navigation through
> dialogs rather irritating.
> 
> 2) Always have Ctrl+Tab insert a tab character, and Tab navigate out. 
> This makes navigation nicer, but breaks our usual meaning of Ctrl+Tab,
> and makes it non-obvious how to insert a Tab character if you don't know
> the trick.
> 
> 3) Don't allow tab characters to be inserted in single line text fields,
> as they're rarely needed.  (But still need to pick 1 or 2 above for
> multiline text fields).
> 
> 4) Allow the programmer to set a flag on the text field that specifies
> whether it allows the entry of Tab characters or not.  If it does, Tab
> should enter the character, and Ctrl+Tab should navigate out. 
> Otherwise, Tab should navigate, and Ctrl+Tab should do nothing.
> 
> We picked (1) for the proposal after discussion with Earl and for
> consistency with Java.  Personally I prefer (2) or (4), but there you
> go...
> 
> 
> > <POB> Ctrl+Right arrow moves cursor to end of current word.
> > <Ctrl+Left arrow moves cursor to beginning of current word.
> > Is the behavior of Ctrl+Left arrow adequate? </POB>
> 
> Yes, that sounds like what I meant.
> 
> > <POB> The behavior extends the selection in the manner expected by the
> > implementation of <Ctrl+Right/Left arrow. </POB>
> 
> OK.
> 
> > <POB> The behavior here depends on whether the function
> > gtk_entry_activates_default() has been called. It seems that the default
> > behavior is for Enter to insert a newline character. It seems that what you
> > are requesting is that the default behavior be changed. An application
> > can easily change the behavior of Enter. </POB>
> 
> This is the other big contentious issue we need resolution on.... should
> Enter always activate the default button in the dialog, or should some
> other key combination do this instead (e.g. Ctrl+Enter)?
> 
> The most common objection to the current proposal is that people often
> instinctively hit Enter after typing into a single-line text field, only
> for the dialog to disappear before they'd finished with it, and
> therefore Enter should actually move focus on to the next control
> instead.  
> 
> Similarly, because Enter is regarded as an "action button", people might
> well try to use it to change the state of the currently-focused checkbox
> or radio button in a dialog, resulting in the window closing instead. 
> (Spacebar is the proposed shortcut for changing the state of such a
> control).
> 
> Also, assuming that we stick with the concept of never changing which
> button is the default once the window is open, this means that when a
> non-default button has focus, pressing Space will activate that button,
> and pressing Enter will activate a different button.  This is guaranteed
> to catch people out.
> 
> So, possible solutions:
> 
> 1) Stick to the proposal: Enter always activates the default button,
> unless the widget with focus uses Enter for something itself. 
> (Multi-line text widget, list control etc.).   Maintains reasonable (but
> not complete) consistency, but easy to dismiss dialog by mistake.
> 
> 2) Pick a different shortcut for "Activate the default button" that you
> wouldn't hit in error, such as Ctrl+Enter.  Enter can then effectively
> be used to duplicate Tab as a navigation key, except in cases where the
> currently-focused widget uses Enter for something itself.  (Multi-line
> text widget, list control etc.).  Gives complete consistency whichever
> control has focus, hard to dismiss dialog by mistake, but not as
> convenient or obvious as just pressing Enter, and could be annoying in
> simple dialogs where the confusion wouldn't arise in the first place.
> 
> 3) Ensure none of the other widgets use Enter for their own purposes. 
> This is a bit of a non-starter, really.
> 
> Again, we picked (1) for the proposal for consistency with Java, and
> because the Java folks presumably gave a lot of thought to it at the
> time.  However, a lot of GNOME folks would like to see (2).
> 
> Cheeri,
> Calum.
> 
> -- 
> CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
> mailto:calum benson ireland sun com    Desktop Engineering Group
> http://www.sun.ie                      +353 1 819 9771
> 
> Any opinions are personal and not necessarily those of Sun Microsystems