It had been causing problems in Unity for a while now and they
were missing on OSX as well in wx3. So, the old menu Open/Close
method of hiding has been removed and replaced with an event
filter/monitor which looks for wxEVT_CHAR_HOOK events to pass
key events to the handler that has the keyboard captured.
It was producing "ghost" windows on OSX in wx3. These were
supposed to be hidden, but they weren't any longer and after
reviewing TipPanel, I realized that there was a separate
code path for OSX entirely...must've gone back to some of the
earliest versions.
Now all platforms use the same bit of code.
This also re-enables the splash screen and recombines the
OnInit() and FinishInits() since I'm pretty sure the progress
dialog was the issue.
I also retested (as much as I could) and cleaned out all of the
little "hacks" the progress dialog gained over the years. With
the new modal handling of wx3, it seems that things are much better
behaved.
However, it seems that wxGTK (at least) has gained some new focus
probs (to be dealt with later).
... miscellaneous direct uses of ZoomInfo::zoom to test and set zoom level.
This includes all the remaining assignments to it.
But moving TrackInfo::PositionToTime and TrackInfo::TimeToPosition into
ZoomInfo and using them is needed to eliminate many more uses.
Also #if'd out the unused AudacityProject::OnZoomToggle().
wx3 on OSX has changed how the mouse wheel delta is calculated. Prior
to wx3, it was simply set to 1 so the wheel rotaion value was simply
increments of one.
With wx3, higher resolution devices (like touchpads) are supported so
the value for wheel rotation can be a fraction of the delta, so it is
possible to pass a zero value to the NumericConverter::Adjust() method.
Therefore, the method just returns in this case.
Since I ran out of time, I put OSX back to the way it was in
2.1.0...forced locale to en_US. Heck, I'm not sure there is
a "real" fix anyway.
At least, the problem languages appear to be happy now, even
when using the validators.
This removes the TrackInfo's slider "cache".
Originally, the cache would build to the maximum number of tracks you
had created in an Audacity session. So, if you created 128 tracks
and then reduced that to 1, you'd still have 256 sliders, 1 gain and
1 pan per track.
But, the only real thing the cache did was prevent continuous allocations
of sliders since the allocated sliders position and values wer still
being updated nearly with ever interaction since they were redrawn each
time.
In April 2010, the slider cache was changed to reduce its size by
creating a sort of ring buffer based on how many tracks were displayed
and how many tracks were in the project (I guess). Unfortunately, it
didn't really handle large number of tracks and this bug was born.
While trying to find the proper fix for this, I realized that the
cache really wasn't saving anything. Maybe a little when dragging
the thumb, but during normal track redraws and interaction, it really
didn't serve a purpose, other than use additional memory.
So, I've removed the cache and have allocated a single gain and a
single pan slider. As before, their position and value are changed
as needed when drawn and manipulated.
When it is enabled, the project can scroll up to one-half of a screenful
beyond time zero or the maximum track time. I was careful to disable selection
of negative times.
This is motivated by the smooth scrolling scrub. It behaves more sensibly at
the extremes. It can still keep the play indicator centered.
Also removed an unused member of ViewInfo.
Discovered a sizing problem when working on the effect registration
dialog and then found that others had mentioned a similar sizing
issue with the TimerRecordingDialog.
