Talk:Proposal: Reserved keys for custom key bindings

From Audacity Wiki
Jump to: navigation, search

Documentation

Gale 28May13: Do we really want to document available keys and maintain that list, even on Wiki? The information would be platform-specific with Windows users having the largest number of available keys and Mac least. Also we wouldn't mention numpad keys as integrated computers tend not to have them, but Desktop users could add numpad keys. This makes the list complicated to explain. Improving Keyboard Prefs so you can sort the list of commands would arguably be just as good.


General feedback

Steve commented 23May13:

  • There may be some overriding case in the future for using a "reserved" combination, so I don't think that we can be entirely rigid on this. On the other hand, every developer, including amateurs such as myself, will be convinced that their case for using a reserved combination is fully justified.
  • Documenting the reserved character may not be straightforward because we are talking about keyboard layouts that are not standard UK/US layouts.

David Bailes commented by email 24May13:

  • If there are going to be shortcuts reserved for custom bindings, I don't think they should include these (the four in Peter's note in the Details section on the Proposal page) - they may turn out to be very useful for audacity features which are introduced in the future, or when current features are made more keyboard accessible. They are standard keystrokes which don't vary with keyboard.

Gale added by email 24May13:

  • +1, especially if the idea is to reserve these for keys that vary with localised keyboard.
  • For example, ALT + LEFT and ALT + RIGHT could become clip navigators.

Peter replied 24May13:

  • Unless we do what Steve suggested later (see above) and have fewer pre-defined bindings - then I'm afraid that I have to strongly disagree with you in this David.
  • The reason that a user wants to set a custom binding is because it is a function that they use an awful lot - and therefore they will seek convenient and easily memorable bindings.
  • The users deserve to have a few handy standard keystrokes which don't vary with keyboard - and the group I suggest is a mere four in number.
  • Because we have so many pre-defined bindings in Audacity it makes it hard for the user to discover an unassigned set of bindings to use.
  • It took me the best part of a morning's work to figure out that set of four that I chose.



Steve wrote by email 24May13:

  • In the long term we probably need an easier way to set access keys and have less options pre-defined so that users can set the ones that they

use frequently to convenient keys that they can remember without clashing with default keys.

  • Would it be better if the keyboard preferences allowed users to reassign key combinations that are in use (with a warning) rather than just saying that it is already assigned?

Peter replied by email 24May13:

  • +1 for fewer pre-defined bindings.
  • The set that we use now is so huge that no one user can remember them all - I'm sure most of use only a smallish sub-set - so allowing the user to define their own may lead to greater uptake and usage.
  • You can already override existing pre-defined bindings. All you need to do is to clear the pre-defined binding and then that binding becomes available for re-assignment.



Gale's comments 24 May 13:

There seem to be two requirements:

  • custom bindings for keys that vary with localisation
  • custom bindings for keys that are common to all keyboards.

I don't think shortcuts for b) that imply navigation are good choices. For example look at the long Forum discussions where users want better/alternative navigation between closed and open labels and between label and audio tracks. Consider that we should have a way to keyboard navigate into clips.

What would be the interface for reserved custom keys?

  • That the Command ("Custom") and reserved Key Combination is at the top of each category in Keyboard Preferences, then user chooses which custom command to associate with the reserved combination from a list?
  • Or that when user clicks in the text box in Keyboard Preferences we somehow let them the see the reserved keys?

Removing current default bindings that users already use will be controversial if those bindings don't actually work any longer in the new Audacity version.

There are already some menu items that arguably should have a default binding e.g. Overdub, Software Playthrough, Mix and Render.

  • Peter 27May13: +1 for shortcuts for: Overdub, Software Playthrough, Mix and Render. Particularly (personally) for Software Playthrough - I toggle that an awful lot when I switch between recording from my external soundcard and recording what's playing on the PC.

The menu item that was introduced in addition to the Preferences setting improved that a lot, but a k/b binding would make it even better.

I think rather than reduce the number of default bindings we should aim longer term to make the Keyboard Prefs easier to use. Things that might help include:

  • Show the same division structure that the Menus have, including the text of menu items that lead to a cascading sub-menu.
  • Make the "Command" and "Key Combination" lists sortable by clicking on the header.
  • Include a Search box.
  • (suggested by Steve) allow users to reassign key combinations that are in use (with a warning) rather than just saying that it is already assigned. Having to clear the existing binding in order to reassign a key already in use is very user unfriendly. It may involve navigating to another category.

Peter's responses to Gale 27May13:

  • OK you've convinced me not to vote for removing any current bindings - I don't want to deal with regression fallout either. I have marked that with strike-through.
  • I only want "custom bindings for keys that are common to all keyboards" - that way we would get a common set that can be documented across all language versions of Audacity and all language versions of the manuals.
    • Gale 28May13: You may only want that, but Steve's original proposal was "perhaps we should reserve special keys that vary on non uk/us keyboards for user's custom key bindings." So should not your proposal include those too?
  • I can see your point about keys that "imply navigation" but they can carry other implications too. The reasons I ended up choosing that set were:
    • Alt+Left & Alt+Right carry for me the mnemonic of the beginning and ending of a "song" within a track and are therefore providev a good personal visual cue for Fade In and Fade Out (actually Studio Fade Out) respectively.
    • Alt+Up I use for Amplify as I am usually using that to Amplify the sound Up.
    • Alt+Down I use for Repair as I am usually fixing a damaged waveform ad settling it back Down to where it should be.
    • Using The Alt key in conjunction with the direction keys implies an Alternative usage.
    • And that group of keys is just so darn conveniently placed - not scattered all over the keyboard - and with a single modifier key, the Alt key
    • Even if a developer in the future decided to use those keys I would probably reset them to the bindings I have now as they are just so useful for LP/Tape transcription work (which is what I, and many others, do most).
      • Gale 28May13: If a developer used your custom shortcuts for a default they would currently fail, as you suggest in your proposal, so there would indeed need to be a mechanism not to use them for future releases. This is why I do not want to use them for bindings of potentially high accessibility value. I am not sure what the logic is, but from tests, either the new default shortcut or the previous custom shortcut would fail, but the shortcut would appear in the menus twice. So that is a problem we already have.
  • If you and David are so set against reserving those key combinations then perhaps one of you could suggest a suitable set that would be equally memorable and convenient that we can review.
      but as far as I can see F7, F8, CTRL+ F7, CTRL + F8, CTRL + ALT + F7 and CTRL + ALT + F8 are free on all platforms for use as reserved keys. Many CTRL+ALT+letter combinations are free. We should not use any of:
      • CTRL+ALT+D
      • CTRL+ALT+H
      • CTRL+ALT+M
      as these are commands for show/hide desktop or windows on Linux and/or Mac.

      And of course Audacity is already using:

      • CTRL+ALT+I
      • CTRL+ALT+J
      • CTRL+ALT+K
      • CTRL+ALT+V
      • CTRL+ALT+X
      This gives the possibility of CTRL + ALT and a QWERTY letter. Some individual CTRL+letters may be free - check the Manual. I know you may object that none of these may be as ergonomically convenient as "yours" - but if we want yours for frequent repetitive navigation that is arguably a stronger case.

  • Peter 28May13: Thanks for the heads up here Gale, good food for thought. I will try to find some time to find some CTRL+ALT+letter combinations that are free. I'm suspecting that we may have a better chance of getting this through if we avoid specifying my nice "ergonomically convenient" set. I propose to stay away from multi-key combinations that include function keys. This is because my laptop keyboard (Toshiba Satellite) has dual uses for the function keys and access to the function keys themselves involves an "Fn" "shift key" to access them - meaning that you get to press four keys instead of three - too much imo.
    • Gale 28May13: OK. F7 and F8 would provide an extra two keys at least. On my laptop and netbook though, if you press Fn on its own this toggles Function keys acting as F keys or doing their special action like controlling wireless or media. So having pressed Fn once, you don't need it again to operate an F key shortcut.

      Remember that CTRL + ALT can be thought of as an "alternative" action for a CTRL shortcut with the same letter. So it may be best not to reserve e.g. CTRL + ALT + C as we may dream up some "alternative" copy command where CTRL + ALT + C would be useful. Ideally too, the reseved CTRL + ALT letters we choose should be next to each other.

    • Peter 29May: On my laptop the Fn key doesn't seem to toggle like yours; I'd still like F7 and F8 - but I'd be loath to suggest those as being single keystrokes and grouped together they would be very appealing for a developer to want to use - so let's keep these on the back-burner for now. Ctrl+letter is fairly barren - there are only two spare G and H. Ctrl+Alt+letter is however much more unfertile ground - good suggestion, there are 10 available combinations currently and I think the 3-key-combination is less likely to appeal to a developer. I will send you by separate email a two-sheet spreadsheet with the results of my research. But we have on the top row a string of 6: W, E, R, T, Y, U and two groups of two on the second row A, S and F, G. There are also Z, B, N on the bottom row. Any preferences? What do you think is the right number to suggest?
      • Gale 02June13: CTRL+ALT+Q is available and not OS-used as far as I can see. CTRL + ALT + QWERTY as six reserved keys would be very easy for user to remember. The only slight objection could be that CTRL + ALT + E and CTRL + ALT + R could be useful (but we do have CTRL + SHIFT + R available as another recording shortcut). I think CTRL + A LT + A (selection) CTRL + A LT + S (saving), CTRL + A LT + F, CTRL + A LT + G (both viewing) and CTRL + A LT + B (cursor play) could all have a possible future claim to Audacity usage.
        • Gale 04Jun13: CTRL + ALT + T is used on the GNOME Desktop (so e.g. on Ubuntu) as default shortcut to open a Terminal window, though that shortcut is not listed in the document I link to above.


Peter 29May13: Idea to aid with spotting available key combinations

Another thought that occurred to me today was: how about if we updated the Preferences:Keyboard so that clicking on the" Key Combination" column header so that it sorts the list into alphanumeric order. That may make it easier to spot available sets of key combinations. Thoughts?

  • Gale 02June13: See my comments from 24May13 above where I already suggested that :=)