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 bool MenuManager::TryToMakeActionAllowed(), there's the condition:
(MissingFlags & enabler.possibleFlags()) == MissingFlags
that is, the missing flags has to be a subset of the possible flags.
For cut in pause mode, this condition is not met for the enabler stopIfPaused, because MissingFlags also includes the CutCopyAvailableFlag, which is not one of the enabler's possible flags.
It is not sensible for the missing flags to have to be a subset of the possible flags, because for this to work, for each enabler the possible flags would have to include other flags that could need fixing by other enablers.
Fix:
1. Change the condition to the intersection of the missing flags and possible flags is non-empty.
2. In CutCopyAvailableFlag, remove the condition !AudioIOBusyPred(). If this is present, then due to the first change, paused audio could cause all audio to be selected even when there was a selection. The commands for which this flag is used are cut and copy, and they already have AudioIONotBusy flags, so this change should not affect previous behaviour.
... Do not include CommonCommandFlags in Menus.cpp, but PluginMenus is
high-level enough to do the special case changing of flags.
see commit 0bd1beae9a
... 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
... 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.
... 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.
Fix:
Call TrackPanel::OnTrackMenu(Track *t) with a track pointer.
Query:
Is there any reason why this function's parameter has a default value of NULL?
... not the best thing for the long term, but hidden dependencies on
TransportMenus.cpp are eliminated
Tying CommonCommandFlags again into the big component, which is now 26
