Re: Keyboard navigation- outstanding issues

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

> Delivered-To: gtk-devel-list gnome org
> X-Accept-Language: en
> MIME-Version: 1.0
> To: usability gnome org, gnome-accessibility-list gnome org, 
gtk-devel-list gnome org
> Subject: Re: Keyboard navigation- outstanding issues
> Content-Transfer-Encoding: 7bit
> X-BeenThere: gtk-devel-list gnome org
> X-Loop: gtk-devel-list gnome org
> X-Mailman-Version: 2.0.5
> List-Help: <mailto:gtk-devel-list-request gnome org?subject=help>
> List-Post: <mailto:gtk-devel-list gnome org>
> List-Subscribe: <http://mail.gnome.org/mailman/listinfo/gtk-devel-list>, 
<mailto:gtk-devel-list-request gnome org?subject=subscribe>
> List-Id: Development of GTK+ <gtk-devel-list.gnome.org>
> List-Unsubscribe: <http://mail.gnome.org/mailman/listinfo/gtk-devel-list>, 
<mailto:gtk-devel-list-request gnome org?subject=unsubscribe>
> List-Archive: <http://mail.gnome.org/archives/gtk-devel-list/>
> 
> Calum Benson wrote:
> 
> > Now that we are (well, Padraig is) finally getting around to
> > implementing the long-standing keyboard navigation proposals, for gtk at
> > least, the two biggest issues we never really resolved are kind of
> > rearing their ugly heads again.
> 
> Well, having collated the responses I got on- and off-list, predictably
> enough, there was some difference of opinion  :o)  However, here's a
> summary of what consensus there was:
> 
> Issue 1: Most support was shown for the idea of allowing the developer
> to choose whether tab characters should be allowed in individual text
> entry fields or not, by means of a flag or similar.  If they're allowed,
> Tab key inserts a tab character, and [Shift+]Ctrl+Tab navigates out of
> the field.  If they're not allowed, [Shift+]Tab and [Shift+]Ctrl+Tab
> both navigate out of the field.  Default should be 'not allowed'.  
> (Perhaps should be 'tab characters allowed' for multiline fields?)
> 
> Problem: This would presumably mean an unplanned gtk patch :o)
> 

I am working on a patch to GtkEntry and GtkTextView for this. Implementation of 
[Shift]Ctrl+Tab will depend on a previous patch for changing the behavior of 
GtkNotebook being accepted.

The default behavior for GtkTextView is allow_tab_character so I will assume 
that is the correct default for multiline fields.

> Alternative: Most people wanted unhindered tab navigation where
> possible.  So, in single line textfields, have Tab navigate out of the
> field, and Ctrl+Tab insert a tab character.  In multiline text fields,
> have Tab insert a tab character, Enter insert a newline, and
> [Shift+]Ctrl+Tab navigate out of the field.  This way, Tab navigation
> works everywhere except for multiline text fields, which occur
> comparatively rarely in comparison to single line fields.  (And where
> they do, you often don't have to tab out of them anyway, if at all--
> e.g. email composer window, word processor).
> 
> Issue 2: Most people seemed to prefer the current proposal, i.e. Enter
> activates the window's default button unless the focused widget makes
> use of Enter itself (e.g. a multiline text field).  A suggested

Currently bug 61561 is causing a problem here for GtkEntry. I assume that there 
is an expectation that the behavior of the Enter and Return keys will be the 
same.

GtkEntry currently has a property "activates_default" which controls whether the 
window's default button should be activated. This proposal sounds like a request 
to remove this property and always activate the button, but I will not do that. 

I am ignoring the suggested refinement, below, for the present.


> refinement was that if the default button is currently disabled, Enter
> should move focus onto the next control instead.  (For an example of why
> you'd ever want the default button to be disabled, see
> http://java.sun.com/products/jlf/ed2/book/HIG.Behavior5.html#46941). 
> Caveat: This puts the onus on programmers to disable default buttons
> when appropriate, and perhaps even not provide a default button for some
> dialogs at all.  (An idea which becomes more bearable if we decide to
> assign mnemonics to "OK" and "Cancel" buttons, another suggestion that's
> been bandied around recently).
> 
> I hate to bring another round of arguments about this down around my
> head with the following phrase, but here goes:  I await your comments 
> :o)  (A decision is getting kind of urgent now, as we've started
> implemeting the rest of the keynav proposals...)
> 
> 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
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list