Keyboard shortcuts
2009-05-01 02:03:07 GMT
I am interested in making our keyboard shortcuts discoverable, ubiquitous, and consistent. This is especially important because of the approximately half a million demon-possessed trackpads that OLPC has shipped (not blaming; I thought that the resistive pad was a cool idea too, in fact, it's still a cool idea and the XO had a pretty good batting average with its attempted miracles).
The overall plan is outlined at http://wiki.sugarlabs.org/go/Design_Team/Vision/Proposals/Keyboard_Action . I've posted it here before, but since I combined it with another idea about the home view, it didn't get discussed much. I'm starting to code it, so I want to get some more consensus before I go too far. I'll start with vision, then talk about implementation.
The vision is to provide software support for three desirable qualities.
Discoverable. Without discoverability, shortcuts are useless. And we have pre-literate kids as a part of our user base, so including "ctrl-x" in our popdowns isn't going to cut it. My basic idea is that when the user presses/holds ctrl, the shortcuts show up as translucent letters in front of the toolbar buttons. Some open questions:
Delay? My instinct is yes, so that fast typers aren't slowed down by UI candy, but a pretty small one - around 300-700 ms. I'd rather not make this configurable.
Non-"ctrl" shortcuts: My idea is to have two lines: the top third of the toolbar button can say "Alt" or "Shift", then the bottom two thirds has the letter. F5 or Pause or whatever should just say the key name. The problem is, how do you distinguish ctrl-alt-a from alt-a, and ctrl-F5 from F5. IMO it's not actually a tragedy if you just don't make that distinction.
Ubiquitous. To me, this goal means increasing our software support for the developer/translator team assigning shortcuts. It's true, it's really just one line and one string per button (customButton.props.accelerator = _('<ctrl>b')) but that's a big nuisance for translators, and programmers are meant to be lazy. So I think you should be able to assign the accelerator from within the translatable string. GTK already has a similar mechanism, but it's inappropriate. Setting the label to "go _next" will, if the use_underline property is true, set the mnemonic, a kind of shortcut that works only if the control's visible, to alt-n, and draw the label with the n underlined. Four problems: we care about tooltip, not label; we want the shortcut to be available when you're on a different toolbar; we want ctrl, not alt; and this doesn't seem to work in sugar, for reasons I've not investigated. So I propose doing the same thing, but using the tooltip, a real shortcut, ctrl, and the character u"\u00ad" which is "soft hyphen", ie, by nature an invisible typesetting mark. Issues: I haven't tested if you can use the backslash escape to get this in Pootle, if not it's a problem.
Consistent. This means dealing with all the shortcuts in a unified fashion. First principle is, ctrl for activity shortcuts, alt for global/frame ones, ctrl-alt for modified ctrl shortcuts (ie, ctrl-alt-v is paste-and-pop-clipboard), ctrl-shift or alt-shift is backwards (redo or alt-shift-tab). Here's my list of global shortcuts/key assignments, copied from keyhandler.py with my proposed changes in bold, please add anything I've forgotten:
_actions_table = {
'F1' : 'zoom_mesh',
'F2' : 'zoom_group',
'F3' : 'zoom_home',
'F4' : 'zoom_activity',
'F9' : 'brightness_down',
'F10' : 'brightness_up',
'<alt>F9' : 'brightness_min',
'<alt>F10' : 'brightness_max',
'XF86AudioMute' : 'volume_mute',
'F11' : 'volume_down',
'XF86AudioLowerVolume' : 'volume_down',
'F12' : 'volume_up',
'XF86AudioRaiseVolume' : 'volume_up',
'<alt>F11' : 'volume_min',
'<alt>F12' : 'volume_max',
'0x93' : 'frame',
'Insert'
'0xEB' : 'rotate',
'<alt>Tab' : 'next_window',
'<alt><shift>Tab' : 'previous_window',
'<alt>Escape' : 'close_window',
'0xDC' : 'open_search',
# the following are intended for emulator users
'<alt><shift>f' : 'frame',
'<alt><shift>q' : 'quit_emulator',
'XF86Search' : 'open_search',
'<alt><shift>o' : 'open_search',
'<alt><shift>r' : 'rotate',
'<alt><shift>s' : 'say_text',
-SOAS
_______________________________________________ Sugar-devel mailing list Sugar-devel <at> lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
--- snip ---
> '<alt><ctrl>Escape' : 'close_window_discard_from_journal',
Not sure what this one is.
--- snip ---
> #... alt-numeral should be like the top row of the frame, so alt-5
> would be journal
> #and alt-6 first running activity
So is the reason behind this idea to help keyboards without any F
keys? Should this not also include the F5 key being made to show the
Journal (equiv. to open_search I think).
--- snip ---
> # the following are intended for emulator users
> # '<alt><shift>f' : 'frame', #removed
> # '<alt><shift>o' : 'open_search', #removed
> # '<alt><shift>r' : 'rotate', #removed
Why the removals?? Now I would have no working keys at all for
accessing the frame!
--- snip ---
> ...
> Also, ctrl-numeral would choose toolbars, and toolbar tabs would get
> little translucent numbers when you held control.
So what happens to an activity that uses some ctrl-numerals already
(labyrinth does)?
For my bike-shed, I'd be happy with F1-F4 as is, F5 can be Journal, F6
could be frame, then we could make little bits of printed card with
icons on, and kids could sticky-tape them just above their F keys 
RSS Feed