#4646 HIGH Update.: Systemwide keyboard shortcuts break terminal apps (e.g. nano)
Zarro Boogs per Child
bugtracker at laptop.org
Mon Nov 5 13:21:22 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:4 bemasc]:
> Replying to [comment:3 Eben]:
> > CTRL is also our primary modifier key, and therefore the one that
should be doing things like save (keep), quit (stop), copy, paste, open
> Save should be a rare event. You should only save if you are
checkpointing because you are about to do something that you may want to
revert. Otherwise, you can just close. There is no need for a save
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
> 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.
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".
> 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.
> > 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 the
Right, this is the point of having it, though, I feel.
> Some activities will have no state, so keep does not make sense.
True, but most will. All of those currently shipping, in fact, do.
> Copy-paste only makes sense for certain activities.
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?
> > I think that terminal apps are a special case here
> > 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...
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?
> > I'm not the authority on this, and I'm spoiled by OSX in which command
provides ubiquitous and consistent shortcuts and ctrl is "leftover" for
use in the Terminal and other such circumstances.
> You should feel equally spoiled on an XO. For example, nobody has done
anything with the lefthand-righthand keys, which are clearly modeled on
Apple's special keys (like openapple/closeapple on the Apple II,
option/command on Macs, etc.). Those would be a decent choice for non-
No, no. The grab keys have a very specific (yet unrealized) purpose.
They are supposed to carry much of the weight currently placed on scroll
bars, which are often unfriendly. The behavior will mimic that of Mac
laptops' two-fingered scrolling, allowing one to pan around any scrolling
view while holding this key.
I suppose in the future we might have touchpads that can sense multiple
points of contact, in which case we could re -appropriate these keys, but
by then their use might be too engrained.
> > Perhaps this does in fact need to be policy, but I ''strongly''
dislike the idea of having some basics such as "keep" and "stop" be
anything but completely standard across all activities.
> I agree that consistency is extremely valuable. However, I also see
chorded shortcut combos as an indication of failure, both in software
design and keyboard design. Computers are supposed to alleviate
repetitive tasks. A keyboard shortcut indicates that the user is being
required to manually execute some simple task on a frequent basis, and
there isn't a key for it. Sugar has removed many of these tasks, and the
keyboard neatly exposes most of the rest.
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).
Ticket URL: <http://dev.laptop.org/ticket/4646#comment:6>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system
More information about the Bugs