...bug began at 52ff705b0dff568512b6c6016936b78311c56a69
Fixing this in a way that does not make a dependency cycle between ProjectWindow
and TrackPanel
Problem:
Currently calling Track::EnsureVisible() also sets the track as focus.
In Audacity 2.3.3 the timing of the code to set the focus was changed. Rather than a direct call, an event is queued, and then the focus is set. This has changed the timing of the focus event which is sent with respect to other focus and name change events. In particular in the case of toggling the selectness of the focused track, this moved the focus event to be after the name change event.
These changes only had an effect on NVDA - Jaws and Narrator were unaffected.
The introduction of this bug has highlighted an existing problem.
1. There are a small number of existing cases where a track needs to be visible, but where it is already the focus, and so setting the focus is unnecessary. For example, pressing Enter to toggle whether a track is selected.
2. Some of the Audacity code which calls EnsureVisible() is written with the assumption that EnsureVisible() doesn't set the focus, and so there are unnecessary focus events. Whilst other code which calls EnsureVisible() assumes that it also sets the focus. Confusion.
The Fix:
Remove the setting of focus from within Track::EnsureVisible(), and so remove the unnecessary focus events.
Calls to set the focus were added before calls to EnsureVisible where the code was relying on EnsureVisible to set the focus. In TrackPanel::ProcessUIHandleResult, and TrackPanel::OnMouseEvent, I wasn't sure if the focus needed to be set, so called it anyway to ensure that the behaviour did not change.
So I would like to remove the setting of focus from within Track::EnsureVisible(), and add explicit calls to set the focus where necessary.
I think this would make the code clearer, remove unnecessary calls to set the focus, and make it easier to keep NVDA happy.
... 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
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.
... Problem involves sequence in which event handlers are done, and started at
commit 278509a which updated track Y coordinates in a handler.
Solution is to delay the updating of scrollbars further, using CallAfter.
Also remove one unnecessary call to ProjectWindow::FixScrollbars() because
ProjectWindow::HandleResize follows it and includes scrollbar update already.
... and updating of them is accomplished privately in implementation files,
reducing intrusions into TrackPanel and ProjectWindow
This removes #include-s from TrackInfo.cpp, leaving dependency cycles better
than previously
... Freeing SelectionBar and SpectralSelectionBar from cycles.
Also fixing a minor problem: if two projects are open, and one is playing or
recording, and you switch windows -- then the audio time in the selection bar
of the other project could be updated.
... As when recording starts or stops, or the Tools button has changed, or
scrolling has changed the results of hit-test.
This reduces TrackPanel's intrusions into other code, including ProjectHistory.
Also for AdornedRulerPanel, which shares the base class CellularPanel
... to break some dependency cycles. Install a callback at initialization time.
This frees CommonTrackPanelCell from cycles, which is important because it is
a base class of Track
... New files, but (almost) empty; don't use the global variable gAudioIO,
but use one of two accessor function names (which are the same function for
now).
AudioIOBase will have fewer dependencies than AudioIO -- in particular, no
dependency on tracks.
It won't include StartStream. It will contain functions to query the
present state of streams, and device capabilities.
Problem:
When the keyboard first moves to the top panel using ctrl+f6, the click to pin button in the ruler is the focus. It should be the first control in the top tooldock.
This problem was introduced by commit: 4abc71c. Prior to this commit the top tooldock was created before the ruler, and afterwards the order was reversed. The default tab order is the order of creation.
Fix:
Explicitly set the tab order of the top tooldock and the ruler, so that the creation order doesn't matter.
