[Sugar-devel] Keyboard shortcuts

[Jameson Quinn]

Oops. Sorry, I didn't know that "tab" was "send" in this gmail's keyboard
shortcuts. Resend, more complete at bottom.

---------- Forwarded message ----------
From: Jameson Quinn <jameson.quinn at gmail.com>
Date: 2009/4/30
Subject: Keyboard shortcuts
To: sugar-devel <sugar-devel at lists.sugarlabs.org>


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'               : 'frame', #for SoaS
    '0x00'                 : 'frame', #for SoaS on Xephyr, see below.*
    '0xEB'                 : 'rotate',
    '<alt>Tab'             : 'next_window',
    '<alt><shift>Tab'      : 'previous_window',
    '<alt>Escape'          : 'close_window',
*    '<alt><ctrl>Escape'    : 'close_window_discard_from_journal',*
    '0xDC'                 : 'open_search',
*    '<alt>1'               : **'zoom_mesh',
 #... alt-numeral should be like the top row of the frame, so alt-5 would be
journal
 #and alt-6 first running activity
    '<alt>Enter'           : 'hide-toolbar', #if implemented by activity
    '<alt>v'               : 'view-source',
    '<alt>c'               : 'screen-capture',
    'PrtSc'                : 'screen-capture',*

*    '<alt>s'               : 'say_text',* #was alt-shift-s
# the following are intended for emulator users
*#    '<alt><shift>f'        : 'frame', #removed*
    '<alt><shift>q'        : 'quit_emulator',
    'XF86Search'           : 'open_search',
*#    '<alt><shift>o'        : 'open_search', #removed*
*#    '<alt><shift>r'        : 'rotate', #removed*

...
Also, ctrl-numeral would choose toolbars, and toolbar tabs would get little
translucent numbers when you held control.

Implementation

Basically, I propose to do all this magic only on the subclasses already
existing in sugar-graphics. Some of this is more-or-less a monkeypatch to
GTK itself, but I am not signing up for dealing with upstream, and in fact
much of this is not even appropriate for upstream. Some of you might feel
that the "ubiquitous" stuff (saving LOC and strings) is not worth the
maintenance headache to do it in such a hack-y fashion. If enough people say
so, I have no problem abandoning that part of the plan.

OK, sorry for the double-post, and none of this is set in stone. I'm happy
to discuss and bikeshed a bit, but I have already started coding, so please
comment relatively quickly if you object to the whole idea.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090430/b460e0d5/attachment-0001.htm