Feature: configurable key assignments

[mpogue2]

Allow users to customize the keys to their preference. Could be a separate tab in Preferences, or a key map file that could be edited.

[mpogue2]

Some great discussion on this topic, from Tim and Dan (I've abbreviated it a bit, feel free to add more info back if you want!):

I intentionally picked more "logical" shortcuts where possible (especially since we're a bit more Mac-centric, so we need to better follow the Mac conventions). We also have some other conventions to follow, e.g. the font size controls follow the convention used by pretty much all browsers. And, there are playlist shortcuts, too...Where it didn't seem to matter much, I picked the SqView keys, as your table shows, and elsewhere, I tried to come up with something reasonable.

However, having said all that, I know that many people are coming from the SqView world, and their fingers are already "well trained" to use the SqView shortcuts. I think it's a reasonable ask for something for those folks, to make it easy to move over.

We do have this issue: https://github.com/mpogue2/SquareDesk/issues/82 open to address this.

I can see going a couple of ways:

• providing an option in Preferences to use SDP shortcuts OR SqView shortcuts (easier to do short-term)
• provide a shortcut editor, and "sets of shortcuts" that emulate SqView (harder to do, but Qt has some nice support for exactly this use case)

Either way, I think we need to address this -- it's a very good point. I'm going to post this email thread to that issue, so we keep this info on-hand until we get something implemented here. Dan, if you want to take a cut at Preferences for this, great! I know you're experimenting with other stuff, too right now... :-)

In any case, thanks Tim for the comments!

Mike

On 7/21/17 1:51 PM, Tim Schares wrote:

Tempo is E-R Pitch is D-F Speed is C-V (speed in not applicable in SqDesk) Volume is B-N Toggle lyrics is T (SqDesk has this) Fade out is Y (SqDesk has this) Play/Pause is SPACE (SqDesk has this) Restart is "." (SqDesk has this) Scrolling lyrics and music list is done using the up & down keys SqView uses the left/right keys for next & back for choreography. I've never played with that part of SqView to know how it works; I think that SqDesk's use of this to move back & forth on the timeline is very handy.

These are the common ones that I use. A full list of SqView keyboard controls can be found in SqView in Options > Hotkeys. In my time calling so far, I have found that the ability to change these items without having to resort to a mouse are pretty valuable.

On Jul 21, 2017 12:03, "Dan Lyke" danlyke@flutterby.com wrote:

<multiple users have>... asked that we have
the same shortcut keys for tempo, volume and pitch as SqView.

... Not shown in the docus ,but I'd guess V is increase speed. I'd also guess that speed is pitch and tempo together, probably a holdover from before libbass did pitch and tempo separately.

[danlyke]

Take a look at 0fb16ff21a80d456ede25842721a7db68b50c338 and see what you think. I'm regretting doing this in the master branch, because it's not easy to merge in or out, but... done is done, I guess.

Hotkeys are configurable in the Preferences tab, there's an option to reset them all to native.

[mpogue2]

OK, not bad...don't worry about Premature Merging...you've always been amenable to making suggested changes, and this actually gets us there a bit quicker! I'm playing with it now, and will provide some comments shortly...

[mpogue2]

OK, some comments... 1) This interface really answers the question "for each key, what is the single function to trigger?".

I think of it the reverse way, which is, "for each function, which key combinations can trigger it?", very much like the Qt Shortcut item in the Property pane (lower right). Also, I think we'll want the ability to decide which of the modifier keys (Shift, Control, Option, Command on Mac) must be there for each key, and which are optional. The reverse way I think gives us that, too.

For example, Add to Top of Playlist is Shift-Command-Left, while Left and Command-Left are currently bound to Backward 15 Seconds. In the current interface, there's no way to distinguish between these two functions, because there's only one "Left" key field (and I don't see expanding it out to all possible combinations, which would be a pretty long list... :-).

In the reverse way, there would be one line per action, I think, and the above example works.

2) Then the dialog might look something like a list of these: QLabel (not editable): [QKeySequenceEdit]

Example: Fade Out: [Cmd-Y, Y]

The QKeySequenceEdit widget is designed for the job of setting shortcuts for functions. Click in the field, then press the key you want, and wait 1 second. Repeat, until you've captured all the keys of interest. I like it also because it's the Qt way to do this (and I believe it's both I18N-ized and cross-platform).

3) The hotkeys tab is pretty tight on space, so we could fit 2 or 3 per line, if needed. We only have about 25-30 functions or so (more than the current 16 in the dropdown list), so we probably would need to fit maybe 3 per line X 10 lines. I think that fits in the same space, provides more function, and allows for the reassignment of all the functions. Might be able to get away without making the contents of the list scrollable (so you can see all the functions at once). Might also be able to logically group them, if we want to.

4) I love the Hotkeys tab name, and its placement. I also love the "Reset Hotkeys To Defaults" button. Future feature: load different sets of compatible keys, like SqView, DMM, CSDS, etc., and add a selector in the Startup Wizard for initial selection.

5) Might also be useful to users to put in there the NON-assignable keys, with a fixed Label (indicating intentionally non-changeable). For example, ESC probably should always be bound to ESC. There probably aren't too many of these.

6) I'm still uncertain how to handle Cmd-I. In the Lyrics/Patter editor it probably should be the standard "make italic", but it's currently "toggle voice Input" everywhere. I am leaning toward never making keystrokes tab-dependent (minor exception: Print always means "Print something", but that something might change). That probably means changing the Toggle Voice Input binding something else, and making "Make Italic" bound to Italic everywhere. Maybe that then becomes a non-changeable one, like Cmd-B (Bold)?

7) In the reverse way, if a key is bound twice, we probably ought to use just the first binding (simplest approach). Alternately, we could ask the user if it's OK to delete the original binding [Yes/No]. This is an issue that the forward way doesn't have.

What do you think?

[danlyke]

1. Yeah, I started with the "each key has a function" rather than "a function can map to N keys" premise. This also makes it conceptually easier to see what happens when you remap a key, rather than it disappearing from somewhere you didn't expect it to.

2. But I did start thinking the other way, so I'm game to using something like the QKeySequenceEdit control.

3. I got those 16 functions by going through the big switch statement and grabbing all the obvious keys, ie: not the combination ones or oo much of the control keys.

4. Initial design started with a pulldown for the settings, with the idea that we'd start with "SquareDesk native", "SqView", and "Custom". Changing a key switched you to the custom block in the pulldown, overwriting if you weren't already there. I played with that concept a little, and realized that a reset was a better mode.

5. I like this. It puts the help and the assignment in the same place. Should be relatively easy to do.

6. I'm okay with only allowing the unshifted/controlled/metad characters to be reassigned. Really I don't expect this to be used much, if we head too far down this route I'd be thinking more about some sort of scripting, and I don't think we want to write the Emacs of editors...

7. See above about this problem. From a data structures point of view, this really is "each key has one function", not "a function has an array of keys"... If we go to the function first model, I'd silently delete the original binding...

But, I also think being able to sort on both columns would be a good thing...

[mpogue2]

re: 6 -- I think I see where you're coming from. It simplifies the problem if we don't allow any of the Modified versions of the Keys to move. However, then Cmd-KEY and KEY no longer map to the same function (and I think they probably should always be consistent). Hmm...

[danlyke]

Expansion on #4: Just to make sure it's clear, yes, I can totally see multiple presets. Should probably also make the core sets not overwrite unassigned keys.

[danlyke]

Hmmm... Okay, looking at QKeySequence to try to go from function to a key sequence, and... ugh. Just had to whine. No way to get a Qt::Key out of it, so this'll involve, I guess, changing the event loop?

It also looks as though the QKeySequenceEdit 4 keys thing is that you can map a sequence of 4 keys into a single QKeySequence event...

[danlyke]

Hmmm... Now that I blew away my preliminary coding in this front, I discovered that it isn't the way the QKeySequence is supposed to be used, but we could use it to get key codes out.

So do we go for an action first option, allow that action to have up to 4 key combinations that trigger it, and I guess if a key is already assigned, we silently drop that original assignment?

[mpogue2]

Yeah, I think dropping the original assignment is probably the easiest thing for a user to understand... but for initial implementation/testing, that might not be necessary, as long as the app doesn't crash when a key is assigned twice...I think even without the dup detection, it would satisfy 98% of the need.

[danlyke]

Okay, take a look at 2ec95f214922eadf3e09199aad9b231a2817eff5

Known problems: I think that there'll be an issue when we create a new key binding, that the key will have been set to "no action" already. Need to think through this a bit.

And need to do a bunch of clean-up, but didn't want to do that until it felt like this was the right direction.

[danlyke]

Also, this doesn't do anything about multiple assignments, it just takes the last one.

[mpogue2]

I like it! I didn't test it thoroughly, but from what I see the entering-keys part works pretty darn well.

Bunch of minor things:

• Actions are editable right now (probably should not be)
• The Key column is pretty wide. Could we use the space on the right for something else? Some simple help text, maybe? e.g. the upper-left going arrow means "home", the lower-right-going arrow means End (I had to try them to see, because even I did not know those symbols). Or, we could get rid of the scrolling table, and just put 2 columns of 8 each? It's fine the way it is, I'm just thinking about how to use more of that white space for something useful.
• Column is "Key", but Tab is "Hotkeys" and reset dialog is "hotkeys". Probably should all be the same. (does everybody understand the term "hotkey"?)
• T is really Toggle Tab (between Music and Lyrics/Patter)
• Volume is - first, then +; others are first + then -; would be nice to be consistent here...
• K is really Load Next Song (only starts playback if auto-play is on)
• Play Song --> Play/Pause, maybe?

These are all minor UX points.... Overall, I think this is excellent! Go Dan Go!!

[danlyke]

Items not mentioned have been corrected in 8106a2350d2c8ea2a4874dcd61a285fedea9637f

• The Key column is pretty wide. Could we use the space on the right for something else? Some simple help text, maybe?

I like help text, I was also thinking maybe putting the default over there...

[mpogue2]

great idea!

[mpogue2]

Fixed one that was missed (Volume +/- ordering), and while I was there, I also reordered the hotkeys into groups, pretty much ordered by the way they appear in the Music Tab from top to bottom. I'm also open to changing the order to something else reasonable, if anybody has a better preference. Fixed by 310be52e0592337247ad5375a8ce2f2f6bd75fb6.

And, I'm moving the remaining item (Key column default or help) to an enhancement, and closing this one.

Dan, this looks great -- thanks for putting the hotkey stuff in!