... in places that need the TrackPanel but only to invoke common wxWindow
methods on it.
This eliminates direct use of TrackPanel by Scrubbing and ProjectWindow
... new attached object, demoted to low levels of the dependency graph, to
loosen some remaining difficult dependencies;
also update it for "Playing at speed" and for changes of language
ControlToolBar, after we make a system to register functions that calculate
necessary minimum widths for status bar fields.
Also let Scrubbing.cpp register its own strings.
Also be sure to size the status field sufficiently for "Playing at Speed".
... Let the window respond to an undo manager event instead, whenever there
is a push or modify
Maybe this makes a few unnecessary redraws that did not happen before. If
that is important, then we should figure out how to put the logic for eliding
the redraw into ProjectWindow, and the extra information needed for the
decision into the events, but not make intrusions in other code all over the
place.
... so the functions that start and stop streams don't really need the
ControlToolBar object.
This also makes the intended momentary push-down of the Stop button visible,
as was apparently intended, when playback stops for other reasons than a
click on that button.
... So that ControlToolBar::StopPlaying now does nothing directly to the
buttons, and can be moved to another place with no dependency on ControlToolBar
... This also causes a momentary push-down of the stop button, which happens
in ControlToolBar::StopPlaying, really to be visible, as was apparently the
intent.
For instance, when playing, then clicking in the quick-play ruler to restart
the play elsewhere.
... so most calls to ControlToolBar::SetPlay are removed. One remains in
TransportMenus, which will not be problematic for untangling dependencies,
and one remains where the toolbar remakes its own buttons.
But the routines that start and stop the streams, importantly, don't use it.
... Move that into ProjectAudioManager instead, and update the button, only to
reflect it, in idle time.
However, AudioIO also has its mPaused member variable, and it is not obvious
that it was always kept the same as the button state. No attempt was made
here to identify and fix any bugs, but only to preserve behavior.
See commit aeece118e8950d2aeee60ef4e1b2a2ee752129cd which changed it from
the original call intended to hide the quick-play indicator in case that is
how the play starts; but other things in that commit were sufficient to
guarantee that
Steps to reproduce:
1. Open preferences
2. Select the keyboard category
3. Scroll down the list by any amount
4. Select an item using the mouse. The list scrolls to the top and the wrong item is selected.
The problem occurs because if the list of shortcuts is currently not the focus, then after a left mouse click, KeyView::OnSetFocus() is called, and setting the selection in that function interferes with the mouse selection.
Fix: In KeyView::OnSetFocus(), if there has been a left down event, don't select anything.
... the bug was introduced at e581fa60d9328cc4c379f840a0cbd0a85179cad5
I think it is better to make TrackPanel::OnTrackMenu crash-proof when
called with the default argument
