#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: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
 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.

 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
 reasonable option.

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

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

 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
 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?

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

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

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