... because the sequence of update of the cache and the use of it were wrong
on Linux, resulting in wrong display when dragging tracks. Finding the
first visible track is too cheap to justify this memoizing of it.
Commit 8eb64f5f71d19a4c634cb8312fd1fa93ac75f17f was not sufficient to fix
the bug, but I think remains necessary.
It feels good to throw away this needless complication.
... It made it possible to get into a state where some of the toolbars
stopped responding.
This reverts commit 67b858ed3ff1c6c84fdb1b505e6ccb882471d6f6.
Works by using the newer and better logic of ToolManager for remembering which
window to focus.
It seems, at least on Windows, that when the toolbar with the focused control
is docked after the end of a docking (of itself or another bar), then focus
remains.
If the bar with the focus is undocked and another bar docks or undocks, focus
is still lost.
... This fix might not be exhaust the possibilities. Some examples covered:
When an undo state is pushed. For instance: Hover over bottom of sole track
for resize cursor, then Shift+C to delete it. (Cursor change used to happen
at Shift key up, now sooner. Maybe your shortcut does not include Shift.)
When an undo state is modified without a push. For instance: hover over right
edge of selection. Hit Shift+Ctrl+A to remove the selection. (Again, change
cursor before keys up, and even if no modifiers in the shortcut.)
When scrollbars change for any reason, such as pinned play or Shift+scrollwheel.
(Clip boundaries may pass your mouse. Cursor change and also snap lines come
and go.)
... Let cell hit tests, and handle preview, know states only, not transitions.
Cell hit tests are passed a mouse state that does not always match the current,
but anticipates the button click to come; usually left, but if the Control
[sic] key on Mac is down, then right.
Thus, pressing and releasing Mac Control in multi-tool switches in and out of
the magnifier cursor.
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.)
Problem: On Windows 10 1703, with the Jaws screen reader running, additional paint messages are sent to Audacity compared with when Jaws is not running. My assumption is this is probably a Jaws bug. In particular, when a project is closed, ToolDock::OnPaint, and AdornedRulerPanel::OnPaint are called.
Fix: changes ensure that these OnPaint functions can be called without causing a crash.
Fixed so that updates to theme are applied immediately. Previously theming only worked properly after a restart with the new theme. Paul found that you could create a Chimera MixerBoard with a track in each of the four different themes.
I chose to completely recreate the MixerBoard on a prefs update, rather than the more fiddly detail of retheming each component of it.
Commands flagged with NoAutoSelect will not auto select, even if the user has asked for it. This is used for Cut and 3 different kinds of delete. We later might extend it to fades and repair.
I've implemented three states for what to do if no selection:
0 - Grey out (no longer used)
1 - Auto-select
2 - Give the warning message and try again.
Now if there is a time selection and no tracks selected, then just select all the tracks, preserving the time selection.
This helps in the case a user has made a time selection, e.g. with selection toolbar, and then clicked on track panel, losing the selection of tracks but preserving the time selection.
I also shortened some repeated cut-and-pasted code.
This fix works by detecting whether the focus window is the TrackPanel, in which case all keys are handled normally. If it isn't the TrackPanel, then the problematic keys do not get sent to our own CommandHandler and proceed on to wxWidgets.
A problem that then follows is that the menu accelerators (which normally don't get a look in) may then convert the event to a menu event and stop it going any further.So it does not get to the focus window.
The fix/workaround for that is to NOT provide accelerators for up, down, left and right arrow in the menus. I'd much rather be able to turn off those accelerators completely, yet still show them to users as hints.
... The return codes were mostly ignored anyway, and exceptions will be thrown
instead.
It seems there was also confusion whether the return values of Track::Paste
and Track::SyncLockAdjust were to indicate success or indicate whether there
was any change. No matter now.
No ellipses in title bar of file open/import dialogs
Auto Recovery Discard dialogs say only recoverable projects are discarded
Capitalised button in Dependency dialogue per MS guidelines.
