Re: [Usability] Re: Keyboard navigation- outstanding issues

[George <jirka 5z com>]

On Thu, Sep 27, 2001 at 06:28:24PM +0100, Calum Benson wrote:
> 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).

Well, with a bit of a hack, an app author can have tab insertion in his app
anyway without a gtk+ patch.  I think this is the best option, as I think
it's easier "user model".  As in it's simpler to figure out what will happen
if I press something.

> 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
> 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 think if we make sure that complex dialogs have no default, then the
problem of accidentally closing dialogs goes away.  Same with the disabeling
of the default button.  It's more burden on the app writer though.

However, here we come to a fun bit.  Apparently unless you use an internal
API, (gtk_window_set_default) you can't "unset" the default button on a
GtkDialog.  This API is exported however, just marked internal.

George

-- 
George <jirka 5z com>
   When the rich make war it's the poor that die.
                       -- Jean-Paul Sartre