#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 bemasc):

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

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

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

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

 > > 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
 the Journal.
 >
 > Right, this is the point of having it, though, I feel.

 If an activity does not support Open, how does Ctrl+O differ from
 Spyglass?

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

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

 As for another modifier key, how about Fn? Fn-letter is currently
 completely open.

 > 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