... 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.
... 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.)
... 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
... This demonstrates the possibility of visitation of the menu tree specifying
other actions.
This dumps the internal path identifiers of the registry -- not the user visible
names.
Note that lines don't exactly correspond with menu items, where there are
command groups such as Align, or special steps such as population of the
recent files sub-menu.
Perhaps this should be adapted as another case of the GetInfo macro command.
... 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
... 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.
... New files, but (almost) empty; don't use the global variable gAudioIO,
but use one of two accessor function names (which are the same function for
now).
AudioIOBase will have fewer dependencies than AudioIO -- in particular, no
dependency on tracks.
It won't include StartStream. It will contain functions to query the
present state of streams, and device capabilities.
... handling the callbacks from the selection toolbars.
Next ProjectFileManager will be split out of ProjectManager, and
ProjectSelectionManager will be used by it during file opening, so separating
files for it avoids a cycle.
... 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.
... Just one low-level function to simply set the variable, and one
high-level function that also pushes notifications. The danger of infinite
recursion in the toolbar code, as in the previous commit, doesn't exist here.
... There was no reason to store the help location preferences as per-project
state. Also move the dialog for quick fixes near its only use in
HelpMenus.cpp.
This takes 22 files out of the big strongly connected component, notably
the much used lower level utilities, ErrorDialog and AudacityException.
HelpSystem itself is still in a small cycle with LinkingHtmlWindow.
