Re: KEYNAV:GtkEntry And Accessibility (bug 53763)

[Calum Benson <calum benson sun com>]

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