... But perhaps we are developing the means to relax even this ban safely.
For instance, why not undo a mistaken AddLabelPlaying command (Ctrl+M) without
stopping the recording?
... This even makes it possible to remove the prohibition of undo and redo
during transport, not that we want to though. Playback and recording will
continue, using track objects that might not be in the current project.
Added preferences for Zoom-Toggle and put into menus.
New helper functions for determining zoom scaling.
Optional EXPERIMENTAL_ZOOM_TOGGLE_BUTTON added, and Light theme updated.
Not enabled for 2.2.2.
... 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.
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.
... Rather, construct them during hit tests (also capturing more state sooner
rather than at Click time, and adding some accessors for later use)
This also fixes bug 1677 by other means and avoids similar problems.
A cell may be implemented to re-use a previously hit handle object, not yet
clicked, in a later hit test, by remembering a weak pointer, but TrackPanel
holds the strong pointers that determine when the object is destroyed.
And the objects will surely be destroyed after drag-release, or ESC key.
For now they are also destroyed whenever not dragging, and hit-testing is
re-invoked; that will be changed later, so that the re-use mentioned above
becomes effective, but still they will be destroyed when the pointer moves
from one cell to another.
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.
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.
When When two clips are immediately next to each other, the GetEndTime() of the first clip and the GetStartTime() of the second clip may not be exactly equal due to rounding errors. The existing code assumed they were equal, and this lead to the wrong clip boundaries or clips being found.
There are a number of ways of fixing this which could be explored. The current solution involves changing only the code for the keyboard interaction with clips.
The fix:
1. The test used for two clips being immediately next to each other is that GetEndSample() on the first clip is equal to to GetStartSample() on the second clip.
2. When searching for the start/end times of clips, the cases where GetEndTime() and GetStartTime() are not equal are taken into account. This is done in the two functions AudacityProject::AdjustForFindingStartTimes and AudacityProject::AdjustForFindingEndTimes.
Problem was that cfd7648fce2388ec8ae35b38004f2ae111c484af 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.
This introduces a new variable, mStopIfWasPaused (default true). Actions which require AudioIONotBusyFlag will now stop the audio, if audio was busy but paused and attempt to continue.
We could perhaps make mStopAudioIfWasPaused into a preference, but I don't think we need to keep even the option of the old behaviour.
