... TrackPanelAx now sends an event to the project when track focus changes,
and TrackPanel listens for it.
TrackPanel also initializes TrackPanelAx with a callback to do the details of
rectangle calculation.
Problem: If the initial focus is a control in a toolbar, then after applying an effect such as amplify, then the focus is read as being a track, not the control in the toolbar.
TrackPanelAx::SetFocus() can be called when the TrackPanel is not the focus, and send a focus event.
Fix: In TrackPanelAx::SetFocus(), only send a focus event if the TrackPanel is the focus.
... Unnecessary because transitively included.
But each .cpp file still includes its own .h file near the top to ensure
that it compiles indenendently, even if it is reincluded transitively later.
Problem:
Using the Narrator screen reader on Windows 10, there are a couple of issues:
1. After making a change to solo/mute/selectedness, the name and state of the track is not automatically read.
2. Text sent to TrackPanelAx::MessageForScreenReader() is not read.
Fixes:
After a focus event, if the focus has not changed, Narrator does not read the name, even if the name has changed. So:
1. In TrackPanelAx::Updated(), add a name change event. (The focus event has been retained to keep Window-Eyes happy until we stop supporting it.)
2. In TrackPanelAx::MessageForScreenReader(), change the focus event to a name change event. Note the Window-Eyes does not read these messages anyway, because when the role is set to wxROLE_NONE it does not read the name. So there's no point in including a focus event for the benefit of Window-Eyes.
... which will make it easier to change the types of those containers to
std::vectors of other string-like classes
for wxString,
IsEmpty => empty
Clear => clear
Alloc => reserve
for wxArrayString,
Count => size
GetCount => size
IsEmpty => empty
Add => push_back
Clear => clear
Empty => clear
Sort => std::sort (only with default comparator)
SetCount => resize
Last => back
Item => operator []
Alloc => reserve
Changes to the state of the track which are appended to the track name, as suggested by Robert.
Mute On becomes Muted.
Solo On becomes Soloed.
Select On becomes Selected
Sync Lock Selected becomes Sync Locked.
Problem. When an effect is applied, whatever track is the original focus, there is a focus event for track one. This causes NVDA to read out the track name of track 1, which is unnecessary noise.
The reason for this is that the execution of the Progress dialog destructor causes AudacityProject::OnActivate() to be called which causes a set focus on the TrackPanel. When this happens, the pointers to the selected tracks have changed, but the final focus has not been set (at the end of AudacityProject::DoEffect()). So TrackPanelAx::GetFocus returns the first track.
Fix: Modify TrackPanelAx::GetFocus so that if the existing pointer to the focused track is null, then use the track at the same position, if it exists.
The main change in wx accessibility is this:
7dab555f71 (diff-04f5191d86f95b1c4d5d9c979da65878)
However wxWindowAccessible has not been updated to take into account of that change. In particular wxWindowAccessible::GetParent() was always wrong, but it was consistent with the rest of the framework. Now it's wrong and inconsistent. This function should return an object with role window, and which has the same name.
The fix is to introduce class WindowAccessible, which is effectively our own version of wxWindowAccessible. This class does not override GetParent(), and so just relies on a standard accessible object to to the right thing in wxIAccessible::get_accParent() (which is does). This class also allows us to have our own version of GetName(), which allows us to set the accessibility names of buttons.
These changes will break the accessibility of Audacity if it is built with wxWidgets 3.0.X. If this is a problem, then there could be some #if stuff in WindowAccessible.h to turn the WindowAccessible class into one which simply inherits from wxWindowAccessible, and doesn't override anything.
After a focused track is removed by pressing shift+c, the new focus is often not correctly read by screen readers, especially nvda.
The fixes:
1. In AudacityProject::RemoveTrack, set the new focus after the track has been deleted, rather than before. (If it is set before, then the childId can be wrong after the track is deleted.
2. In TrackPanelAx::SetFocus, send an object focus event if there are no tracks. This is so the focus is correctly set when there are no tracks after a track has been deleted.
3. In TrackPanelAx::GetFocus, given the change in 2. , only call SetFocus if the focus has changed, to avoid sending unnecessary focus events. (Screen readers are normally tolerant of this, but Window Eyes became a bit too talkative.)
Fix for bug introduced by commit fb18f6a: mFocusedTrack needs to be updated before the focus event is sent to ensure that when TrackPanelAx::GetState is called, mFocusedTrack is the focused track.
... Formerly it was outside of the yellow focus at the right side. Now it
follows the yellow consistently on four sides.
The constant dx in TrackPanelAx::GetLocation might be adjusted.
No change of behavior is intended at other uses of FindTrackRect
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".
Problem was that cfd7648fce 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.
To reproduce the bug: open audacity, press r, then spacebar to record some audio. The track is not the focus - the track panel is.
This was caused by commit 519a202. Most of the changes in this commit were latter reverted in commit 80e19f2, but not the changes to the file src/TrackPanelAx.cpp
The fix is to go back to the version of TrackPanelAx.cpp in commit db35301, the commit before 519a202.
... This affects those keys (and NUMPAD arrows), also (shift-)ctrl-f6,
ctrl-home, ctrl-end (which are command-left and right on mac)
Those should be tested to ensure correct restoration of the yellow rectangle,
appropriately in the tracks or the ruler.
This should also be tested with and without the Tracks preference for cyclic
movement of the focus.
