Problem:
Currently KeyboardCapture::Capture(this) is called in TrackPanel::OnTrackFocusChange().
So the keyboard handler is not automatically set when the track panel becomes the focus.
Example of a symptom:
A project contains a label track, and is the focus, and type to create a label is enabled.
Move to focus to another window, and then back to the Audacity window.
Type a character. A label is not created.
Fix:
Move the call KeyboardCapture::Capture(this) to TrackPanel::SetFocusedCell(), so that it gets called when the TrackPanel becomes the focus.
My previous fix for this bug, commit 4b437b8, did not work on Mac.
This bug was introduced by my commit b62ed73. This commit was to ensure that when the keyview was the focus, there was always one item selected. This ensures that the focus is indicated visually, and that the Narrator screen reader reads the keyview.
The failed fix, selected an item if necessary when the keyview became the focus.
The current fix reverts b62ed73 and 4b437b8, and ensures that an item is selected each time the items are updated.
... Six files now are in five strongly connected components:
TrackPanel uses
AdornedRulerPanel which uses
ProjectWindow which uses
ProjectAudioManager and Scrubbing (in a small cycle we will leave alone),
and also, ControlToolBar uses ProjectWindow.
This introduces new files for ScrubUI and ProjectStatus and did much cutting
and pasting of code across files. The separation of ControlToolBar
from ProjectAudioManager is especially important.
... this is a remnant of the abandoned experiment that put other buttons in
the ruler besides the pinned play head
See commit 6a3613e8e97da5164da881a179f1b64ac098d472
... The first, being only a user interface for the second, which has no
direct dependency back on it.
Several other places now use ProjectAudioManager directly, not using
ControlToolBar.
Also eliminate the namespace TransportActions from ProjectAudioManager. Either
make new member functions, or inline them because they are short, or move them
to more appropriate files.
... which was redundant with what happens in the yield to idle events in
ProjectAudioManager::Stop.
This removes direct dependency of ProjectAudioManager on ControlToolBar.
And remove another #include we don't need
... 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.
