a) Fixed root cause, which is conversion of a
negative integer to a large unsigned, leading to
a very tall track.
b) Improved mitigation (in projects that already
have over tall tracks) by setting a smaller minimum
for the allowed size.
... This makes it impossible to forget to include the EXPERIMENTAL definitions
(such as when cutting and pasting code) and so get unintended quiet changes of
behavior.
The EXPERIMENTAL flags are now specified instead in new file Experimental.cmake
... because the two macros have the same expansion, and are both checked for
in the --keyword arguments passed to msgfmt by locale/update_po_files.sh.
This commit makes ONLY such changes, and comments in Internat.h. It is big
but quite harmless.
The intention is to introduce a type distinction in a later release, by defining
XXO differently. XXO is used where & characters in strings (for hotkeys of menu
items or control prompts) are permitted, XO where not.
... and we use them to simplify (the misnamed) MenuManager::ModifyToolbarMenus.
It looked wrong that statically constructed menu descriptions should ever hold
constant boolean checkmark values, rather than functions to re-eveluate the
checkmark state as needed.
... They all use the registry.
(This link dependency was not shown in diagrams generated by scripts/graph.pl,
because it was not reflected in Menus.h but was done using extern declarations
within Menus.cpp. That was a cheat, but it let all the other dependencies
be exposed in the graph and mitigated first.)
... removing link dependencies on them from src/menus, so they are now suitable
for moving out into modules.
They are:
Mixer Board
Karaoke (also called Lyrics)
History
Contrast
Plot Spectrum
Their header files are now no longer included anywhere but in their own
implementation files!
... Problem with static initialization order of ReservedCommandFlags, caused
wrong enablement of menu items (at least on Mac), such as Plot Spectrum or
Contrast enabled when there was no selection
... which is not yet used for anything.
It could be used to describe textual paths for attaching plug-in menu items.
Strings are only path local, not necessarily globally unique, and may be
left empty for separators and for groups that should be transparent to
path identification.
It may also be empty for certain sub-menus, such as those that group effects
according to the changeable criteria in Preferences.
... Except a few where project or plugin manager state or preferences are
needed to compute the items, so evaluation is delayed, often inside lambdas
Comment "Delayed evaluation" wherever there are exceptions
... and deduce whether to exclude from macros inside NewIdentifier, simplifying
argument lists further
Also fix the localization of "..." added to names by PluginMenus.cpp
... Let the window respond to an undo manager event instead, whenever there
is a push or modify
Maybe this makes a few unnecessary redraws that did not happen before. If
that is important, then we should figure out how to put the logic for eliding
the redraw into ProjectWindow, and the extra information needed for the
decision into the events, but not make intrusions in other code all over the
place.
... and eliminate some unnecessary calls to SubstitutePendingChangedTrack,
because the track and the substitute store Y and height in their shared
TrackView object.
Also make GetMinimizedHeight() virtual to avoid inclusion of TrackPanel.h in
TrackView.cpp.
... Mostly into CommonCommandFlags.cpp, but some elsewhere, to avoid giving
that new file problematic dependencies on LabelTrack, ControlToolBar, and
EffectManager.
Note that CutCopyAvailableFlag is critically ordered, for message purposes,
only with AudioIONotAvailableFlag, the only flag with a message that it combines
with in menu item definitions.
The dependency on LabelTrack.cpp might not be a bad one later, if the track and
its view can be separated, and that would allow CutCopyAvailableFlag to be
put with the others. But much other work on LabelTrack must happen first.
... that is, a factory function, open, close, import, undo/redo/rollback.
Also the callbacks from AudioIO, which need to invoke undo history push when
recording stops.
It is meant as a high-level class using several of the other things attached
to the project, while AudacityProject will be a low level class acting mostly
as just the container of the attached structures.
... 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.
... use registered factories instead, so class AudacityProject needn't know
the other classes.
This frees 9 .cpp files, related to various non-modal dialogs, to higher
levels out of the big strongly connected component, as determined by
scripts/graph.pl!
But in reality there is still link dependency on them that the script does not
detect. The remaining dependency is via the declarations of ViewMenu,
EffectMenu, etc. in Menus.cpp.
That could be broken with a registration system for menus.
James Crook
Paul Licameli