In response to a comment in #6722, as there is little delineation between the
ruler and track canvas areas it makes sense to keep the scrolling step the same
to avoid unintended jumps in scrolling if mouse cursor moves between areas.
This means that mouse zoom scrolling behaviour is consistent on the ruler
canvas area and track canvas area.
The config option defaults to true so this means the behaviour of Mixbus will
be unchanged but in Ardour the ruler area will now follow the option so by
default will use the mouse position as zoom focus when zooming rather than the
zoom focus setting.
Keep the same scrolling distance per event as when scroll left/right is used.
Scrolling in the ruler area is different than the track canvas area which I'm
not sure is a great idea as there is not much delineation between the two areas
but as the ruler area has some other different behaviour it is probably
acceptable/useful.
Keep scroll distance consistent when scrolling up and down with horizontal
modifier as when scrolling left to right.
Scroll horizonally by half a page so that no sections of the canvas are skipped
when scrolling.
Scroll by half a page rather than a step like when scrolling in the track
canvas area as it is a summary area so larger steps seem acceptable and having
it use the same scroll distance as when scrolling in the track canvas seems
pointless as you would then just scroll in the track canvas area.
Each MidiRegionView(MRV) is connected to the Selection::ClearMidiNoteSelection
signal that is used to notify the all MRV instances to clear their note
selection.
The MRV class also has a private static SelectionCleared signal that is used to
signal other MRV instances when their selection has been cleared. When the
Selection::ClearMidiNoteSelection signal is emitted it causes each MRV to also
emit the SelectionCleared signal. So the emission takes quadratic time.
With 1500 MRV instances emission takes about 2.2 seconds on my machine, and
some operations like track selection cause it to be emitted 3 times(another
issue).
The Selection class in the Editor knows which MRV instances have note
selections, as it is notified by MidiRegionView whenever the selection count
becomes zero or becomes non-zero. Clearing the Note selection should then just
be O(N) and direct calls can be used rather than signals.
This change removes both the signals and uses the existing references between
Selection and MRV class to control note selection. There should be no
behavioural changes in Midi note selection with this change.
