#4646 HIGH Update.: Systemwide keyboard shortcuts break terminal apps (e.g. nano)

[Zarro Boogs per Child]

#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                 |  
-------------------------------+--------------------------------------------

Comment(by Eben):

 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
 (resume), etc.
 >
 > 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
 shortcut.

 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
 everyone.

 > 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
 Journal.

 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
 >
 > Certainly.
 >
 > > 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-
 interfering modifiers.

 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