... Move some fields used only during formatting into a temporary structure.
(And fixing a minor problem with uninitialized variables in case of logarithmic
scale, which made it unpredictable how Plot Spectrum with logarithmic
frequencely axis formatted numbers.)
... and also draw the zeroes if in range, taking precedence over the extreme
values (which might be positive dB values when zoomed out or scrolled).
See comments 10 and 11 in the bug report.
... 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.
... 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.
... 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
... This was motivated by punch and roll recording: it appears most convenient
to pin the head for recording purposes, and drag it near the right, but when
stopping and finding the splice point for the correction, it is better to
scrub unpinned.
... also make popup menus at right up, not down, for consistency with other
popup menus in TrackPanel
Base class also does the event propagation "hack" for ScrubPoller
... All updates of position are done in DoGetRectangle(). Ruler need only
expose one function, DrawOverlays().
Don't redraw indicators twice when dragging (hiding and showing again), making
some flicker. Just do one update.
The main point of this is not to ask for overcrowded rulers.
We already handle overcrowded rulers well, by not showing the minor ticks.
This change means that we are more likely to ask for a spacing that works.
In turn that means that we are less likely to have anomalies where numbers disappear due to overcrowding and reappear again as you resize the ruler.
The problem was actually more general, and involves misalignment between selections
in clips and selections in the background and in the ruler - so could be seen with just
audio tracks and no label tracks.
