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

 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.  These are all functions that every activity should support, and
 should obviously be consistent across them.

 Right. This belongs on the wiki, in the user interface guidelines. It is
 not something that should be enforced by the sugar shell, the sugar
 libraries, matchbox, or any other program.

 > I think that terminal apps are a special case here, because obviously
 activities like Paint should be first class members of the system and
 adhere to these standard shortcut rules.  I'd be willing to bet that most
 of the overlap you found in TuxPaint was for key bindings for the same
 purposes.

 Sure: undo, redo, open, new, save, quit, delete

 I may wish to remove some of these, but that doesn't make it OK for sugar
 to swipe them.

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

 It seems to be standard for terminals to require the shift key. This even
 extends to mouse operations for those rare terminal apps that use the
 mouse. Thus copy is shift-ctrl-c, paste is shift-ctrl-v, and so on. Note:
 this DOES NOT mean you can steal shift-ctrl-c via matchbox or the sugar
 shell or similar; it only means that the Terminal activity could implement
 things this way.

 > What do others think about this?  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.  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 dislike that too, but the activity author is the person to decide what
 is appropriate.

 Another example: I'm thinking of eventually doing a music app. Modifier
 keys would be used much like the pedals of a piano, to indicate slurs,
 etc. If you steal ctrl-c, then there is one note that simply can't be used
 with the ctrl modifier.

 Looking toward the future, it would be nice to get things into a state
 such that the older/smarter kids don't have to throw away sugar just to
 use xemacs or the gimp. Stealing shortcut keys is one of the numerous
 things blocking this.

-- 
Ticket URL: <http://dev.laptop.org/ticket/4646#comment:9>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system