Re: ComboBox keybindings

[Calum Benson <Calum Benson Sun COM>]

On Fri, 2004-03-05 at 09:02, Matthias Clasen wrote:

> in my quest to get the new combobox widgets in shape for 2.4, I've come 
> around to look at the keybindings. Here is what is currently implemented:
> 
> when the popup is not displayed and the focus is in the button or in the 
> entry of a editable combo box:
> - Alt-Down  displays the popup
> - Down/Up, Page Up/Page Down, Home/End  change the selected 
>   item without displaying the popup

Sounds good.

> when the popup is displayed in menu mode:
> - regular menu keybindings 
> - Alt-Up  hides the menu without changing the selected item

Sounds good.  (I assume Esc works too, by way of it being a "regular
menu keybinding"?)

> when the popup is displayed in list mode:
> - Esc, Alt-Up  hide the popup without changing the selected item
> - Return, Space  hide the popup and change the selected item
> - Down/Up, Page Up/Page Down, Home/End  move the selection 
>   in the list
> Note that Page Up/Page Down should move page-wise, but the 
> list mode doesn't support scrolling yet...

Sound good too.

> There are some points on which I'm not 100% sure:
> 
> - Should we use Alt-Up, Alt-Down to toggle display of the popup
>   (inherited from GtkCombo, also seen in e.g. IE) or Ctrl-Up, 
>   Ctrl-Down as in the aging keybindings document? 

Hmm, well, every other toolkit I can think of uses (or at least allows)
Alt-Up/Down, so I guess Alt would get my vote nowadays.  IIRC The idea
behind recommending Ctrl was to offer some consistency with Ctrl-down in
a notebook, which moves focus from a tab into the page, but I don't
really recall why we thought that was important, and I can't really
think of a convincing reason now either.

> - Should Tab work to hide the display and move the focus when
>   the list is displayed? 
>   Pro: 
>     +makes Tab navigation more consistent
>     +IE does this as well
>   Con:
>     -might feel a bit strange, at least in menu mode, since Tab
>      doesn't normally work like that in menus
>     -the case might be stronger for entrycompletion, where the
>      popup works more like a very specialized input method

Well, if you consider menu mode to be functionally equivalent to a group
of radio buttons, it does actually make sense for Tab to select the
currently-focused menu item and move focus on to the next control. 
(That is, the same thing happens if you move focus into a group of radio
buttons, then select the item you want with the arrow keys, then press
Tab.)  So I'd be inclined to say yes, Tab should do this.

> - Should the keybindings document be updated?

Definitely, it's been on my TODO list for about two years now :/  The
GNOME Accessibility Guide actually has a more accurate summary of the
current state of keynav for people who just need a good reference, but
of course that lacks the toolkit comparison chart of the old document
you're talking about.

Cheeri,
Calum.

-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson sun com            Java Desktop System Group
http://ie.sun.com                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems