Consistent scrolling behavior

[theGreatWhiteShark]

The scrolling in Hydrogen shows a couple of inconsistencies resulting in some "hidden" features. Pressing [Ctrl] when scrolling on top of a rotary, e.g. the knob controlling the instrument gain, or a note property in the note properties ruler the speed of incrementing/decrementing will be slowed down by a factor of 5. Pressing [Ctrl] while up-down or left-right scrolling in one of the editors will increase speed by a factor of 10. Other widgets, like the faders, won't alter speed at all.

I would suggest we pick one consistent way (increase or decrease) to alter speed and implement this for all widgets. I think the particular factors can very well be widget dependent. AFAICS this is not that much work in terms of code.

Let's see which parts of the GUI this will affect

1. Rotary and Knob
2. All fader
3. LCD displays (Improve the LCDSpinBox widget and use it in the instrument editor #1176)
4. Note properties in the note properties ruler
5. Cycling through the different options in LCDCombos
6. the horizontal position of the playback track is altered by scrolling. But I'm not sure if this is a feature and will survive Design of Playback track #1018. But probably not since it doesn't seem to introduce an offset.
7. Song and pattern editor

did I forget anything?

I would tend to favor the "slow per default and increase in speed by pressing [Ctrl]" option since this is the default one in Qt (see https://doc.qt.io/qt-5/qabstractspinbox.html#details). 5., 6., and 7. do already inherit this default behavior.

[Ratfink]

My preference would be for matching Qt's default behavior as well, making Ctrl increase the speed everywhere. It seems like the path of least resistance for us, as well as causing less surprise to users who are familiar with other Qt programs that have the same behavior.

[theGreatWhiteShark]

In the same vein I would suggest Ctrl + → should move the cursor e.g. 5 grid cells at a time. Right now, this key combination just scroll the view at a normal speed (without moving the cursor).

(For the project I'm working on songs are easily >10min long. For the one opened right now I need 7s to get from the beginning to the end of the song when pressing →. But it feels like much longer)

[cme]

Ctrl+←/→ do have a default binding on Linux, MoveTo{Previous,Next}Word. I will add this to the pattern editor / song editor shortcuts for some reasonable amount of motion for 1.1. Unfortunately it doesn't have any equivalent symbolic names for Ctrl+↑/↓.

I think at this stage it feels like using the Qt standard key sequences is starting to get in the way more than it's helping, so as part of the general user definable key work for 1.2 we should maybe abstract the mapping and just use the Qt standard key shortcuts to initialise default bindings?

[theGreatWhiteShark]

Ctrl+←/→ do have a default binding on Linux, MoveTo{Previous,Next}Word.

Yes! This is what I had in mind. When considering a grid cell as a character and using an average word length of 5 - according to Robert Bringhurst's The Elements of Typographic Style - moving 5 cells would emulate this behavior.

Unfortunately it doesn't have any equivalent symbolic names for Ctrl+↑/↓

Historically they would be associated with "move up/down one paragraph", e.g. in Emacs or nano. But this, unfortunately, got lost in the age of web browsers. But I think this is not relevant at all for us. In the grid-based editors there is a symmetry allowing to move up and down as easy as to move left or right. In text this is a completely different story. So, I would suggest that the arrow keys 5 cells at a time in any direction.

I think at this stage it feels like using the Qt standard key sequences is starting to get in the way more than it's helping, so as part of the general user definable key work for 1.2 we should maybe abstract the mapping and just use the Qt standard key shortcuts to initialise default bindings?

You mean the scrolling currently bound to Ctrl+→? I think this is almost save to drop. Apart from 1.1 I doubt anyone would the keyboard while interacting with the grid and in 1.1 moving the cursor does automatically scroll the view as well.

Also I'm not sure how well established these default Qt sequences are. I was quite surprised to see that the speed up in scrolling is not present (thus, explicitly disabled) in both QtCreator and QtDesigner. They not seem too confident about them either :D

But exposing them in the mapping is a good idea. I would actually go as far as exposing the plain ↑/↓/←/→ as well in order to allow a vi-style interaction. (I thought about a moveCursor( directionEnum direction, int nSteps ) function that could be used for all of them and would also allow to expose "the page up/down[/left/right]").

[cme]

It turns out the up/down equivalent keys (Alt rather than Ctrl) are mapped to {Move,Select}To{Start,End}OfBlock on macOS. There's no default binding for that on Linux Qt so I'll use that and add a default binding to Ctrl+up/down if it's not bound.

Also, perhaps it would make sens for the Word move operations to move a quarter note in the pattern editor rather than a fixed number of grid cells?

[cme]

Yuck, I didn't realise the bindings for QKeySequence::StandardKey can't be user-defined. I must resist the urge to start refactoring...