#4646 HIGH Update.: Systemwide keyboard shortcuts break terminal apps (e.g. nano)
Zarro Boogs per Child
bugtracker at laptop.org
Mon Nov 5 14:44:28 EST 2007
#4646: Systemwide keyboard shortcuts break terminal apps (e.g. nano)
Reporter: bemasc | Owner: Eben
Type: defect | Status: new
Priority: high | Milestone: Update.1
Component: interface-design | Version: Development build as of this date
Resolution: | Keywords:
Verified: 0 |
Replying to [comment:7 bemasc]:
> Replying to [comment:6 Eben]:
> > I'm not sure save shouldn't get a shortcut just because it's used less
frequently. An easy way to perform the task when it ''is'' needed is
usually a nice thing to have. Perhaps I'm just holding on to a lingering
fear of the "old" save metaphor, but it still seems like offering standard
shortcuts for most of the actions in the activity toolbar would be a good
thing. We also decided to retain as many legacy shortcuts as possible, to
make transitions both from and to the XO from other platforms easier for
> I'm not opposed to the existence of shortcuts, but if you look at how
non-technical people use computers, you'll see that they don't use
keyboard shortcuts. Most Office users click Edit->Copy every time they
want to copy something, even though it says the shortcut right there in
the menu. You can expect the same behavior on the XO, regardless of how
many shortcuts you provide. Since shortcuts will be undocumented and the
mnemonics will not make sense to the users, you can expect even less
The shortcuts will appear to the right of the action label in the palette
(primary or secondary), so they will be exposed just as on any other
platform. Your point about mnemonics is certainly valid.
> My primary concern is that activities be able to override and deactivate
shortcuts, for whatever bizarre uses they desire. Only a handful of
special keys should be trapped by Sugar, to ensure minimal functionality
like the ability to exit the activity.
This is fair enough. The ability to override the defaults could be a
> I see near-zero value in "legacy" compatibility. After all, our legacy
is Unix, so why not adopt Emacs' defaults (or vi's; both are the result of
decades of development)?
Well, it's also for "reverse-legacy" compatibility. That is, while we
certainly don't intend the XOs to be a training tool for "real laptops"
(as protagonists might refer to them), I don't see reason not to make such
a future transition easy. If Sugar gets adopted more widely, I also don't
see why we should change some of these familiar standards (in the desktop
world anyway...emacs and vi are niche markets).
> > > Quit (which triggers a silent save) should be a single keypress,
Esc. No chording necessary.
> > I disagree with this. Making an "invasive" action a single keystroke
is a mistake in my opinion. I say invasive because, although the activity
should auto-save, it could easily disrupt any ongoing networked
activities, which may depend on synchronous or real-time events that would
be hard to resume gracefully.
> Single keypress, single mouseclick.. what's the difference? I think Esc
should precisely duplicate the functionality of clicking the Stop-sign
A fair argument. I'm just afraid that it's easier to kit that key by
accident. (I could be wrong.) Specifically, the escape key lies right
next to the search key, which I imagine will be a popular hit target.
While the stop button is single-click, it resides in the activity menu,
which is almost never visible while using an activity, and so the act of
stopping requires first focusing the toolbar, and then traveling to the
> > Additionally, esc is always treated as the way to "back out" one
level. This should remain true in Sugar, allowing one to back out of a
modal dialog, or a palette or an option list of a selected popup, out of
fullscreen mode, etc. If pressing this key once too many times
accidentally closed the entire activity, that would be a bad thing. Esc
is supposed to make you feel safe, providing a way to back up a step
without "messing things up".
> We already have direct access to all the levels via F1-F4. This is
I wasn't clear enough in my terminology. By "back a level" I did not mean
to refer to the zoom levels at all, but levels of "focus" so to speak (a
popup menu within a rollover palatte within an activity, for instance).
This is a separate concern.
> > > Open is already done by the spyglass key. If context-aware
filtering is desired, this key should implement that.
> > This is true, but we overrode the shortcut specifically because some
activities implemented their own variations on this type of feature, and
we want to reinforce as much as possible that the Journal is the place to
resume things. This is also another place where the legacy shortcut helps
teach those unfamiliar with Sugar.
> Your target audience has never used a computer. Ever. I'm still not
sure what purpose Ctrl+O serves.
I want this system to be easily usable by anyone, really. But I see your
point. The suggestion arose because newly ported activities (from other
platforms) already had implementations for such shortcuts that were
interfering with the system. We thought that overriding them "the right
way" (with the Journal) would prevent this in the future. So it wasn't as
much a decision to add this, as it was a decision to override the default
for misbehaving activities. I wouldn't be sad if this shortcut went away.
However, I'd also argue that if we ''don't'' care about legacy shortcuts,
then we should be free to institute a global set ourselves without caring
that some other activities being ported or developed might have wanted
them. They can work around them. (This is just a thought, and not really
a stance I'm taking. Obviously it doesn't work for the shell...)
> > > > These are all functions that every activity should support, and
should obviously be consistent across them.
> > >
> > > Most activities will not support Open, since resume is initiated in
> > Right, this is the point of having it, though, I feel.
> If an activity does not support Open, how does Ctrl+O differ from
It doesn't. ''No'' activity should support open. The point was to
override it, as noted above.
> > Copy almost ''always'' makes sense. Paste only slightly less so. We
want to make transporting data around between activities as easy as
possible, and we need to encourage every activity to support these
features as completely as possible. In any case, you can't argue that
these are secondary enough not to need standard shortcuts, right?
> Indeed. For rev2, I would say that we should have copy-paste keys.
Perhaps so. I think I'd like that. Maybe the middle slider which has
never really been used should be copy/paste/undo/redo?
> > > > As far as Terminal goes, I'd argue that we should map the controls
as usual when directly within the shell, but ignore them when there is a
process (such as nano) in the foreground, allowing the controls to
function within the process until exited.
> > >
> > > Nope. Bash binds many of the Ctrl-* shortcuts, and some of the
Alt-* shortcuts, to its own features. See http://gentoo-
wiki.com/TIP_Terminal_Keyboard_Shortcuts for a few of them. All standard-
keyboard shortcuts must be disabled in Terminal, all the time.
> > That just sucks. No copy/paste to/from Terminal is a failure. No
ability to stop the Terminal with a standard keystroke is a failure. No
ability to save the current environment (env variables, command history,
etc.) to the Journal for resuming later is a failure. We need to figure
out a way to handle these actions...
> Terminal currently doesn't support Keep/resume at all. I would say the
ideal future solution for those things is just to make them all mouse-
> > It seems that for this reason, we really would have needed another
modifier key unique from control. How does Windows handle this? They use
control as a primary modifier (for things like copy, paste, save, etc.),
right? Do they not have overlap?
> Windows doesn't ship with Bash. Historically, DOS shells used F-keys for
shortcuts; I don't know what they do these days. Gnome-terminal uses
Shift-Ctrl-C/V for copy/paste, and has its own shortcut configuration
> As for another modifier key, how about Fn? Fn-letter is currently
Hmm, that's true. We'd initially spec'd that fn would be reserved for
modifications which were printed on the keyboard. It's also sadly small
for a primary modifier. Perhaps we should rethink that key, though, as
there are very few function key functions left in the latest keyboard
> > That's an interesting view. I would also say that they offer a
quicker and more efficient option than the mouse can offer, which is
especially important for any repetitive tasks. Sure you could just add
more keys (although we couldn't...the hardware was fixed before any
software/design team was around to say anything about it) There is
certainly a tradeoff between the efficiency of one-key shortcuts and the
overwhelming nature of a vast number of keys on a keyboard, especially
when some of those keys are for lesser used tasks. Two-key shortcuts are
a fairly nice middle ground, which retain legacy mappings and offering at
least some form of mnemonic. You'll note that we explicitly rid the
system of 3-key shortcuts, instead specifying that the alt-key should
perform alternate versions of the corresponding control key actions (copy
& erase vs. copy).
> To be completely precise, my philosophy on this matter is that every
function on the system should be available through the keyboard.
Abstractly, the keystrokes should resemble a Huffman code, with the most
frequent tasks being assigned the shortest sequences (1 press) and the
rest sorted by frequency. If any single task is assigned two shortcuts,
this reduces the efficiency of the system by making the second shortcut
unavailable for other uses.
This is a very logical explanation. I like it.
Ticket URL: <http://dev.laptop.org/ticket/4646#comment:8>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs