[Sugar-devel] Keyboard shortcuts

[Jameson Quinn]

Eben, I'd like your comments on the discoverable/floaty-letters idea too.

2009/5/1 Eben Eliason <eben.eliason at gmail.com>
>
>
> > I'd vote for caps lock. This is, of course, somewhat more radical than
> most
> > of my other suggestions, so needs discussion.
>
> Hmmm, not sure. It seems to me that if the zoom-level buttons live in
> the F-keys, then the Frame button should as well. This keeps it at the
> top of the keyboard, as on the XO, and keeps a consistent single-key
> path to a very important element of the UI.
>
> And, for what it's worth, I don't think that activities should need to
> mess around with the F keys. I'd just as soon have banished them
> entirely, as the caps lock key, were they not required for
> compatibility. I think that activities should be using, for the most
> part, the ctrl shortcuts. Perhaps F5 - F8 should be reserved so that
> they can serve for the middle slider on the XO, and we can make one of
> F9 - F12 the Frame key?


OK, but what do we do with the volume/brightness controls that are currently
in F9-12? The other issue is that keyboards are inconsistent with the high F
keys - for instance, the classmate has F11/F12 on the same key (ie, F12 is
fn-F11).


>
> I find the alt-shift-n suggestion to be highly confusing myself. It
> sounds like a good way to accidentally close things, and I'm not sure
> I see the need in the end. Just press alt-n to switch to the activity,
> followed by alt-esc...


OK, that was just an offhand idea.


> >>> # 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!
> >
> > Because they're inconsistent with the master plan, and
> > highly-non-discoverable too.
>
> Could we map any of those that would be dropped in the F9 - F12 range?
> For consistency, I guess we should have an "overlay" key there next to
> the frame key. Could rotate and/or search live there as well?


OK, the grand unified proposal for these, after discussion on IRC and the
above is:
f,j,r,s,v,p,o -> frame, journal, rotate, say, view source, screenshot
("print"), overlay (unimplemented)
<alt><shift>[fjrsvp] = deprecated, but kept for emulator users on MacOS.
<alt>[fjrsvp] = preferred method for above, discoverable through holding alt
and reading the "cheat sheet".
F9-F12 = frame, journal, overlay, view source
This order is changed from the XO, because of netbook keyboards missing
dedicated F11/F12 keys. I'm agnostic about view source needing a dedicated
key.
Insert = frame (redundant)
xo keymaps revised so that the volume and brightness controls are NOT
F9-F12, but XF86AudioLowerVolume etc. F9-F12 would not be available from the
XO keyboard.


>
> >>
> >> --- 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)?
> >
> > could it use F5-F8? I don't know what it does with these. In practice,
> the
> > activity could get them by assigning them before creating that toolbar;
> > ideally, I'd like this to be a consistent standard.
>
> Hmm, I can see ctrl-n being useful to many activities....but tab
> switching would be advantageous as well. Could we use relative
> navigation for tabs, in the form of alt-right and alt-left, or
> similar? This might be more intuitive for kids than counting, and
> would't eat up as much of the shortcut space.


I'd prefer ctrl-something, as it would make it easier to find shortcuts
while holding ctrl. I think arrow keys is dangerous, plenty of editors want
ctrl-arrow to mean something. The options then are "[" and "]"; "," and ".";
";" and "'"; or "-" and "+". Of these, I think that "," and "." are the best
combination of logical (think < and >), non-obscure, and
uncommon-as-existing-shortcuts (ctrl-bracket and ctrl-plus are too common).
The floaty discoverable letters could show < and > on the next and previous
tabs. This is a bit more work to code than just the numbers, but it's
doable. The downside is keyboard layouts which move these keys around, but I
don't see an easy solution for that (except to redundantly map ctr-< and
ctrl->).

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090501/9a09f326/attachment.htm