... as a preparation for splitting up class AudacityProject.
Use ProjectWindow as an alias for AudacityProject, and fetch it from the
project with a static member function, where certain of its services are used;
pretending they are not the same class.
Use global accessor functions to get wxFrame from the project where only
wxFrame's member functions are needed, so there will be less dependency on
ProjectWindow when it becomes a distinct class.
... Rename it as SetStatus; make it part of AudacityProject not
TrackPanelListener; and use a roundabout event signalling to cause the timer
restart.
Because SetStatus will be one of very few things left in AudacityProject, but
the timer handling will be part of another class decoupled from it.
And TrackPanelListener won't really be needed: TrackPanel will not need to
pretend it doesn't know what an AudacityProject is.
... Reimplement the ESC key handling in TrackPanel and time ruler on all
operating systems so that it does not rely on the focused window, but instead
uses the application-wide event filter.
This includes reversion of 9491605cfc
... except Audacity.h; and in no others.
Do so even if Experimental.h gets multiply included, as in both the .h and
.cpp files.
This makes it easier to do a text scan to be sure there are no unintended quiet
changes of meaning because of omission of Experimental.h when the flag is
an enabled one.
Also move inclusions of Experimental.h earlier.
Also don't require Experimental.h to be preceded by Audacity.h to define
EXPERIMENTAL_MIDI_OUT correctly.
... Make all line drawing go through our AColor which wraps the wxDC
line-drawing functions.
Despite what wxWidgets documentation says, the functions still don't
consistently include the first point and omit the last point of a line. I
observed inclusion of both on Mac, while on Windows, omission sometimes of the
first point instead of the last.
Discrepancies could be observed in 2.3.0 between Windows and Mac, using the
Window magnifier or command+alt+ +, zooming in closely on the ends of the
shadow lines below and right of tracks, or at the bottom-right corners of the
bevels drawn around vertical rulers.
So where there is an observable one-pixel difference of drawing between
platforms, there is the question, which was the intent when the drawing code
was written? Should the coordinates be corrected by one or not?
I reviewed each case and used my judgment.
Most of the calls are in drawing rulers. Major tick lines were drawn five
pixels long, and minor, three, on Mac. I keep this behavior, but you might
argue for making them four and two.
On the other hand the drawing of ruler grid lines, which you can see in
the equalization and frequency analysis windows, did need a one-pixel correction
to avoid straying out of bounds.
Paul Licameli
Steve Daulton