This reintroduces the buttons to toggle display of individual midi
channels, and cleans up the code behind that feature.
This functionality has actually been present in production versions of
audacity for a while, at least for clicking. However, the buttons
themselves were not drawn, making it exteremly painful (but possible) to
use.
As requested by PRL, this is always enabled if USE_MIDI is defined.
Clip Left
Clip Right
If the cursor lies within a clip, the clip and the cursor is moved 1 pixel left/right.
If the cursor position is at both a clip end and a clip start, the second of these clips is moved.
The movement currently ignores the snap to setting on the selection bar, and there is no snapping to the clip boundaries of other clips.
Following the behaviour or shifting with the mouse, the distance moved is rounded to an integral number of samples, and the minimum distance moved is one sample.
This gets rid of the offset rectangle hack that was needed to re-use gain
sliders for note track velocities. It also removes the need for changing
the style of a single slider. Perhaps most importantly, it fixes link
errors regarding GainSlider(int).
See https://sourceforge.net/p/audacity/mailman/message/35752524/ for
details on why this change is needed and what caused it.
The two commands are "selection to next label" and "selection to previous label".
They have default shortcuts alt+right and alt+left.
A label track does not have to be the focus. If there is a single label track in the project, that it used. If there is more than one label track, then the first label track, if any, starting at the focused track is used.
If the commands are used during playback of the project, playback continues from the new cursor/selection.
The commands provide feedback to screen readers: the name of the label, and position in the form of "i of n".
I also took the opportunity to modifier the Status Bar indications when in the TrackInfo.
1) We now mention ctrl click can select or deselect track.
2) If there is only one track, we don't now prompt about rearranging tracks, since you can't.
3) If you hover in a label track's VRuler (which is just a spacer so that things line up), you now don't get a message.
Progresses us a little towards closing. Ctrl-Click on waveform now removes track selection status, not just adds it, and we don't flicker on again subsequently when we drag. Ctrl-Click won't remove the last remaining selection (by design). Shift-Click can now reduce us down to one track, rather than the previous behaviour when reducing track selection.
Problem was that cfd7648fce2388ec8ae35b38004f2ae111c484af fixed a memory leak
but created a dangling pointer bug, which does not happen during usual run
of Audacity because AudacityProject::OnCloseWindow is reached then before
destroying AudacityProject.
Fixed it by using a std::shared_pointer for the TrackList that both
AudacityProject and TrackPanel must use.
The function builds pop up menus that are never displayed and
creates runtime debug warnings. It is left over from PRL's experiment
in 2.1.2 with a context menu for the vertical ruler.
... See comments #1 and #2 at
http://bugzilla.audacityteam.org/show_bug.cgi?id=1331
Don't make strange undo history if, e.g., R to record (or other keystroke
with undoable effects) interrupts a drag with undoable effects (like time
shift). Ensure that by first simulating a mouse button up event to stop the
drag, before dispatching the keystroke.
Don't crash if certain other drags, that do not have undoable effects, such
as selection or vertical ruler drag -- are interrupted by a keystroke
command (Ctrl+C in particular could cause crash). However, in these cases,
the drag is still allowed to continue.
... activated by clicking near the left end of the ruler, then using the
context menu.
This is not finished work, but a proof of concept for a possible new scrubbing
UI.
... So it does not depend on the focused window, and can work when selection
toolbar has focus. But TrackPanel's escape handling may still take precedence
over it.
... for functions in final classes.
override is like const -- it's not necessary, but it helps the compiler to
catch mistakes.
There may be some overriding functions not explicitly declared virtual and I did
not identify such cases, in which I might also add override.
... Should have no effect on generated code, except perhaps some slight faster
virtual function calls. Mostly useful as documentation of design intent.
Tried to mark every one of our classes that inherits from another, or is a
base for others, or has abstract virtual functions, and a few others besides.
