#4646 HIGH Update.: Systemwide keyboard shortcuts break terminal apps (e.g. nano)
Zarro Boogs per Child
bugtracker at laptop.org
Mon Nov 5 14:15:20 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 |
Frankly, I think your time is too valuable for this debate right now.
Someone should fix Terminal, and we should deal with this later.
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
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.
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)?
> > 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
> 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
> > 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.
> > > 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
> 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.
> > > 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
> 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.
Ticket URL: <http://dev.laptop.org/ticket/4646#comment:7>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs