Systemwide keyboard shortcuts break terminal apps (e.g. nano)

[bemasc]

In joyride-228:

Ctrl+O is a systemwide shortcut to bring up the Journal. The system's command-line text editor is nano, in which ctrl+o is the command to save a file. Thus, it is impossible to edit files in Terminal, because the save command is intercepted and opens the Journal instead.

Solution: 1. Terminal should deactivate all keyboard shortcuts. 2. ctrl+o should be removed. It exactly duplicates the functionality of the magnifying-glass key, in addition to interfering with other activities.

[AlbertCahalan]

All of these need to go. Far more than Terminal gets messed up. The XO keyboard has plenty of exotic keys to use, plus a frame. There is no need to swipe regular keys from the activities.

I just checked Tux Paint. It wants: Alt-S Ctrl-Shift-Esc Ctrl-Z Ctrl-R Ctrl-O Ctrl-N Ctrl-S Ctrl-D

Contemplate an emacs activity.

FWIW, this is also an ICCCM violation. You're not supposed to ever steal keys. Stealing the non-standard keys shouldn't be a problem though.

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

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

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.

[bemasc]

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

Quit (which triggers a silent save) should be a single keypress, Esc. No chording necessary. Open is already done by the spyglass key. If context-aware filtering is desired, this key should implement that.

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. Some activities will have no state, so keep does not make sense. Copy-paste only makes sense for certain activities.

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.

What do others think about this?

A dangerous question.

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.

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.

[Eben]

Replying to bemasc:

Replying to 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).

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

[Eben]

Replying to bemasc:

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

[AlbertCahalan]

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

[dsiegel]

Replying to AlbertCahalan:

Left hand please meet right hand.

I just turned up ticket #4591, which globally binds ctrl-s in activity.py, thus preventing me from using emacs properly.

I've just disabled this "feature" on my XO.

Guys, globally binding keys in Sugar is a bad idea, even if you want consistency for the kids. Doing so in multiple places in the framework is just nasty.

I've probably wasted more than a day, all told, trying to fix this.

OK, finished venting. I'm still happy to be a G1G1 participant.

[grumbel]

After a week playing with the OLPC I can say that having Sugar stealing Ctrl and Alt is really bad. Sure, the OLPC isn't intended for normal Linux/X11 apps, but in the end I have very little doubt that it will be used for them, since not each and every application will have a sugarized equivalent and there isn't a good reason to make running legacy apps harder then it should be, especially when the fix is so easy:

The hand-keys aren't used for anything. From what I could figure out their only intended use is for thumbpad-scrolling, so why not use them for all global keybindings that Sugar might need in addition and leave Alt and Ctrl to the applications. This shouldn't cause any trouble for existing apps and still provide easy to reach keyboard shortcuts.

[Eben]

Replying to grumbel:

After a week playing with the OLPC I can say that having Sugar stealing Ctrl and Alt is really bad. Sure, the OLPC isn't intended for normal Linux/X11 apps, but in the end I have very little doubt that it will be used for them, since not each and every application will have a sugarized equivalent and there isn't a good reason to make running legacy apps harder then it should be, especially when the fix is so easy:

Ctrl and Alt have traditionally been used for many of the very same shortcuts that we have adopted them for. In fact, this is specifically why we chose to use them for some of our canonical shortcuts. That said, I understand that it's better to make this a policy in some cases than to force it upon all activities. I don't think that this warrants arbitrarily changing all of our recommended shortcuts.

The hand-keys aren't used for anything. From what I could figure out their only intended use is for thumbpad-scrolling, so why not use them for all global keybindings that Sugar might need in addition and leave Alt and Ctrl to the applications. This shouldn't cause any trouble for existing apps and still provide easy to reach keyboard shortcuts.

The fact that the hand keys aren't used is unfortunate, but they do have a very well defined purpose which will be implemented, hopefully sooner than later. I don't want to confuse matters by mapping shortcuts to these keys.

[mtd]

I know now's not the best time for peanut-gallery comments/patches, but I'll toss this out anyway:

• #5376 has made terminal able to copy & paste from the keyboard
• ctrl-o, ctrl-s, other shortcuts seem to be OK to remove (see below)

I'm attaching three patches:

4646-0001) revert ctrl-s from #4591 - useful for deployments and addresses the original purpose of this ticket.

4646-0002) remove non-contentious keyboard shortcuts (see below for rationale) - not detrimental for deployment usage (see below, again)

4646-0003) add back emulator-required keyboard shortcuts, but with additional <ctrl> modifier key (in front of <alt>) to make them much less likely to interfere with activity shortcuts.

I split this up into three patches because:

• 4646-0001 I imagined to be trivial / agreed; and

• 4646-0002 to have no effect on deployments and be in line with my interpretation of eben/bemasc's exchange:

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.

...as:

1. NOT allowing removal of any keyboard shortcut involving a keyboard key that has an XO-specific image/glyph (this reserves all the F-keys, and the XO-only keys on the keyboard and monitor like search, overlay, rotate, dpad, etc.) and/or are obviously required for minimal sugar

functionality (this reserves ctrl-esc for exit/quit activity and alt-tab and ctrl-alt-tab for obvious window-switching features) - this is all justified, IMHO, by eben agreeing with bemacs's "only a handful of special keys should be trapped by sugar, to ensure minimal functionality . . ."; and

1. allowing removal of any keyboard shortcut that is not required by minimal sugar functionality - this is all justified both as the converse of what eben's agreement with bemasc means and also as a consequence of eben explictly not objecting to removing the Ctrl-O shortcut ("I wouldn't be sad if [the ctrl-o/open] shortcut went away").

The only contentiousness I can see (if I've interpreted eben/bemasc sympathetically) with this patch (4646-0002) is that non-XO users of sugar could lose access to the functionality now only available with the XO-only keys (e.g., rotate, overlay). I argue 1) this is not a concern for any deployment; and 2) this can easily be addressed by choosing different, less likely-to-interfere shortcuts. As I'm less comfortable choosing these shortcuts and without these shortcuts all deployments can still make full use of Sugar/XO, I defer the choice of these alternates to a 4646-0003 so this patch (4646-0002) can easily be cherry-picked.

• ...and 4646-0003 to be contentious and definitely none-of-my-business (aka needs eben/someone's blessing on the choice of new modifiers). I imagine these <alt><somekey> shortcuts were added mainly for emulation (on non-XO hardware) developers/users because they duplicate other shortcuts (except for screenshot). I've made them <ctrl><alt><originalsomekey>. As they're already not-required-for-XO-hardware / dupes I suppose they are grandfathered / don't conflict with eben's "[we eliminated] 3-key shortcuts" / bemasc's "[a single task shouldn't be assigned two shortcuts]".

[mtd]

Now that joyride's open again might someone consider pulling the attached 4646-0001 patch to enable Ctrl-s and the 4646-0002 patch to enable Ctrl-o for all apps, including nano (as the title of this trac requests?).

(bump)

[mtd]

Here's a patch.

It's one line.

It satisfies the ticket and is consistent with eben's last comment on the matter ("I wouldn't be sad if [ctrl+o] goes away.")

I'm going to assume people are too busy with update.1 to do this and give up on this ticket for a few more weeks. If somebody would let me push it from my git I'd shut up for longer ;).

bash-3.2$ git-diff keyhandler.py 
diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index b07f46c..f6ff54f 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -59,7 +59,6 @@ _actions_table = {
     '<ctrl>Escape'   : 'close_window',
     '<ctrl>q'        : 'close_window',
     '0xDC'           : 'open_search',
-    '<ctrl>o'        : 'open_search',
     '<alt>s'         : 'say_text'
 }
 

[AlbertCahalan]

Replying to mtd:

Here's a patch. It's one line.

It looks like you forgot Ctrl-q.

[marco]

Eben, are you ok with ctrl+o removal? What about ctrl+q?

mtd please remove the implementation of open_search too.

[mtd]

marco: as requested:

diff --git a/src/view/keyhandler.py b/src/view/keyhandler.py
index 82b6b1c..655e12b 100644
--- a/src/view/keyhandler.py
+++ b/src/view/keyhandler.py
@@ -60,8 +60,6 @@ _actions_table = {
     '<alt>p'         : 'previous_window',
     '<ctrl>Escape'   : 'close_window',
     '<ctrl>q'        : 'close_window',
-    '0xDC'           : 'open_search',
-    '<ctrl>o'        : 'open_search',
     '<alt>s'         : 'say_text'
 }

AlbertCalahan: not sure what you mean. I'm happy to remove Ctrl-q (consider my 4646-0002 patch), but I figured if I just stuck with the original request it'd start the ball rolling.

[marco]

mtd, you need to remove this part:

    def focus_journal_search(self):
        bus = dbus.SessionBus()
        obj = bus.get_object(J_DBUS_SERVICE, J_DBUS_PATH)
        journal = dbus.Interface(obj, J_DBUS_INTERFACE)
        journal.FocusSearch({})

    def handle_open_search(self):
        self.focus_journal_search()

Also please provide the patch as an attachment, or send it to the mailing list (preferably using git-format-patch). Thanks.

[mtd]

Oh I'm sorry, I understand what you meant by "remove the implementation" now. I don't think I want to remove your code, because we still want the dedicated keyboard key which looks like a magnifying glass, to bring up the journal, right? My last "patch" removed that mapping because I misunderstood what you meant by "remove the implementation".

[marco]

Doh, sorry I see now! OK, so your first patch is good to go in as soon as Eben approves it.

[mtd]

Cool -- so should I send a git-format-patch version to the mailing list for eben to approve, or do you expect he would approve in trac and then I should send the patch to devel@ to be merged by someone?

[tomeu]

Hi, I applied Martin's patch for removing the <ctrl>o shortcut. Is there anything else to do in this ticket or can be closed?

Thanks!

[AlbertCahalan]

Replying to tomeu:

Hi, I applied Martin's patch for removing the <ctrl>o shortcut. Is there anything else to do in this ticket or can be closed?

<ctrl>q needs to go as well, and anything else involving <ctrl>.

[mtd]

There is more to do on this issue, though I'm happy to open another trac: please consider my three patches detailed in comment # 14 ( http://dev.laptop.org/ticket/4646#comment:14 ).

In particular, grabbing Ctrl-s is so evil I can't believe it (as an emacs user it means I can't use it from the terminal, and the justification provided in #4591 for stealing this key is/was very weak (and, indeed, that is pointed out by bert in comment # 7 of that ticket ( http://dev.laptop.org/ticket/4591#comment:7 )).

Basically I read the long, wide-ranging comments before #14 as approving the removal of many (in my mind, disruptive) shortcuts.

My one line patch was an act of desperation, not capitulation :). Again, I think that my patches from comment #14 address everyone's issues and are consistent with all of the principles exposed in the prior discussions.

If not, feel free to close. But it'd be nice if the patches were considered.

[mtd]

I've submitted a combined version of my earlier two patches to sugar@… after feedback from eben, bemasc, and others.

[cscott]

What's the current status of this? See bugs #7072, #6146, and #4591. We had a visitor here at the country meetings who was disappointed that Terminal didn't allow him to ssh into his mail reader (emacs on a remote machine).

I don't feel we need to remove the bindings completely (although I wouldn't object if we did) -- being able to *unbind* them in Terminal would be sufficient, since the problematic Ctrl-O and Ctrl-S shortcuts don't actually do anything useful in Terminal anyway.

[mtd]

Current status: tomeu pushed my one line Ctrl-O-removal patch to sugar's git a while ago. As for many of the others, nobody is arguing for their continued existence, and I submitted a patch to eliminate this issue: http://lists.laptop.org/pipermail/sugar/2008-April/005418.html .

[Eben]

There was a lot of discussion around the aforementioned patch a little while back. I'm OK with the changes contained therein, so I'm assigning this back to Sugar for integration.

[mtd]

Pushed this to sugar's git repo ( http://dev.laptop.org/git?p=sugar;a=commitdiff;h=07bddbe8484736217546da0204f9aefde65ec805;hp=0f53a912018be99022cd8c1ea233bde3738eb1e4 ).

Please forgive the resolution / keyword changes if inappropriate.

[mtd]

We've regressed on this in joyride-2491, and I suspect 765. Ctrl-s is stolen in Terminal, and rather than getting passed through to the terminal, appears to save/"Keep" to the journal.

09:46 < tomeu>         activity_toolbar.keep.props.visible = False
09:46 < tomeu> so I guess the problem is that the button is there
09:46 < tomeu> just not visible
09:46 < tomeu> so we should actually remove the button

[mtd]

(In #7072) This was fixed, but now isn't. Linking to #4646 for posterity.

[mtd]

Attached patch to fix Terminal. Other activities will need patching, too, if they use the standard toolbar but don't want the standard accelerators.

|TestCase|

Run Terminal. Press Ctrl-Q. Terminal should not exit.

|TestCase|

Run Terminal. Press Ctrl-S. Terminal should not create a journal entry.

[gregorio]

Is this one closed? If so, please update the status.

It has a note for release notes but I can't tell what to include. If you think it does deserve a release note them please help me write something succinct and user readable.

FYI the only documented keyboard shortcuts I know of are these: http://wiki.laptop.org/go/Keyboard_Shortcuts/8.2.0

I would consider anything else a feature request.

Thanks,

Greg S

[mtd]

Replying to gregorio:

Is this one closed? If so, please update the status.

It's not closed in joyride or candidate-8.2 streams. The status is accurate AFAICS - it needs review.

It has a note for release notes but I can't tell what to include. If you think it does deserve a release note them please help me write something succinct and user readable.

The release note tag is old. There is already a release note section for this on the wiki that I'm happy with (since I made it :)), so perhaps this tag should be removed?

FYI the only documented keyboard shortcuts I know of are these: http://wiki.laptop.org/go/Keyboard_Shortcuts/8.2.0

I created that page. Ctrl-S is not on it. Thus stealing Ctrl-S is bad. That (and other shortcuts that were stolen) is what this ticket is for.

Please reconsider the blocks: tag, or at least polish. It'd be a real shame to ship a Terminal where the default editor is broken, again (one year or so on).

Thanks, Greg S

Martin

[cscott]

Can we work around this in the Terminal activity? We probably won't make a 768 just for this, but we could make an updated Terminal available through the Software Update control panel.

[mtd]

Replying to cscott:

Can we work around this in the Terminal activity?

Yes - that's what my patch does, because the new problem isn't really the same as the old one, though the symptom (what's described in the ticket title) *is* the same. In retrospect perhaps I should've opened a new ticket (even though the description would still be the same, so...argh.)

We probably won't make a 768 just for this, but we could make an updated Terminal available through the Software Update control panel.

I know (to both clauses), which is the reason I say it's a shame (and not a blocker or something that should cause more histrionics than my own :)). But yeah, that'd certainly fix the problem. Perhaps if 768 happens for some *other* reason we could put this in, but I grudgingly agree the blocks- tag (which, if we're still using, I think is what GregS meant to put in, so I'm putting it in).

[sayamindu]

Patch looks good. I'll add this patch and release a new Terminal sometime today.

[sayamindu]

Please test Terminal-v19

[Quozl]

Tested using Ctrl-V prefix in shell, on os9, 12.1.0.

Ctrl-Q quits, raised #11835. Ctrl-Z does not work, raised #11836.

Marking this ticket fixed, see the other tickets for progress.