[Sugar-devel] Keyboard shortcuts
eben.eliason at gmail.com
Fri May 1 09:57:54 EDT 2009
On Fri, May 1, 2009 at 9:04 AM, Jameson Quinn <jameson.quinn at gmail.com> wrote:
> (note: I suggest below that we use caps-lock as the frame key)
> 2009/4/30 Gary C Martin <gary at garycmartin.com>
>> Still think this is a tough, disruptive sell for very small gains. We
>> should focus on getting activity authors (and sugar) using the now fully
>> functioning accelerator feature to self document shortcuts.
> Which part? This is actually three separate proposals: "discoverable"
> (translucent letters), "ubiquitous" (auto-assignment), and "consistent"
> (rearranging). Your comments about "consistent" are below, but I don't know
> if the above refers to "discoverable" or "ubiquitous". If you mean that
> ubiquity is a small gain, noted; if you mean discoverability, I disagree and
> would like to hear you elaborate your argument.
> Also, since I'm coding, "tough" is a weak criticism.
>> Anyway, just some quick comments:
> and responses
>> On 1 May 2009, at 03:28, Jameson Quinn wrote:
>>> I am interested in making our keyboard shortcuts discoverable,
>>> ubiquitous, and consistent.
>> --- snip ---
>>> '0x93' : 'frame',
>>> 'Insert' : 'frame', #for SoaS
>>> '0x00' : 'frame', #for SoaS on Xephyr, see below.
>> None of my 3 Mac laptops has an Insert key, and the standard keyboard that
>> ships with iMac desktops also has no insert. Think all Macs currently ship
>> with such keyboards, sans numeric pad, though you can make a custom order
>> for "Apple Keyboard with Numeric Keypad"... actually, just checked that key
>> layout as well and no insert key either – but hey, you get 19 function keys
>> for your money ;-)
>> --- snip ---
> I hadn't seen this, I only knew from wikipedia that if your keyboard does
> have insert Apple sees it as "help". Looking at a few pictures of Macbook
> keyboards, I have to say I like the minimalism, but it leaves few options.
> F5-F8 should ideally IMO be available to individual activities. That leaves
> caps lock, or key combos (I'd favor close-up combos such as
> 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?
>>> '<alt><ctrl>Escape' : 'close_window_discard_from_journal',
>> Not sure what this one is.
> Close the activity but don't show the naming dialog. Delete the resulting
> journal entry.
Makes sense. A nice use of alt in the desired manner.
>> --- 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).
> This is for keyboards without F keys, but it also gives a natural way to get
> the journal and individual activities. alt-shift-N with N>5 could be "close
> activity N-5". I think that F5 should be available to individual activities,
> so I'd vote against F5/Journal. I'd accept the majority decision, though.
Yeah, I think using the alt- shortcuts for the Journal is logical. It
would be more logical if we didn't have to duplicate F1 - F4 with
alt-1 through alt-4, since then the Journal could just be alt-1, but
for keyboards without F keys I guess we need the duplication. I agree,
as mentioned above, that F5 - F8 should be left open, to mirror the
middle slider on the XO.
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...
>> --- 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!
> 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?
>> --- 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.
>> 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 ;-)
I like the thought, but suggest pushing Search(Journal)/Frame to F9
and F10, leaving the "middle" of the F keys open to take the place of
> OK, that's a vote. I vote against you. May the best bike-shed win! (And
> since I don't understand what your position on discoverable and ubiquitous
> is, I can't count your vote there).
More information about the Sugar-devel