... 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!
These are ancient and "configunix.h" was being pulled in
via Types.h. Nothing major, but they were generated for
a 32-bit system and "may" cause problems when used on
64-bit systems.
(That's unlikely though since they haven't all this time.)
Caused by this commit: 0021a98091a70b : Remove another unnecessary stripping of accelerators from labels
Unfortunately, the stripping was necessary.
Fix:
Reinstate stripping.
Derives from tag: Audacity-2.3.3 + 94 commits
The fix follows the agreed behavior (see emails from around October 25) . For the sake of convenience see the agreed behavior below:
_"- first, check the xml-file. If it contains illegal shortcut duplicates, refuse importing. Shortcut duplicates are LEGAL if default settings also have those operations with the matching shortcuts. A refusal to import shortcuts must happen with the message that warns the user of a failure and explains the reason.
if the xml-file looks ok, import the shortcuts. As discussed before, because different versions of Audacity might have different sets of operations with shortcuts, it is still possible to end up with illegal shortcut duplicates for a perfectly correct xml-file. This situation must be monitored. In case of any conflicts, the shortcut from the xml-file is used, and the pre-existing shortcut is wiped clean.
When telling the user the commands which have had their shortcut removed, I think it would be useful to tell the user the name of the command, the shortcut, and and name of the command which still has that shortcut."_
I didn't find a clean way to intercept the imported content before it makes its way to the shortcut preferences, so I had to jump through some hoops right in KeyConfigPrefs::OnImport().
In general, I tried to keep changes minimal.
... without ugly fragile hacks making assumptions about number and sequence of
other menu items. Instead, specify where new items go with textual paths.
... Now, a first-time registered item can specify that it go at the start or end
of the nodes under its parent, or before or after some named node.
Still it might happen that multiple first-time registrations might use the same
ordering hint, and so we must still sort by component name to resolve that
collision arbitrarily.
... before we populate the registry.
This could apply to menu items, or more generally to other registries.
A registry is a tree of items identified by path names. Various code,
that need not coordinate, can specify items to attach to the tree, and the
merging procedure collects them into a single tree that can be visited.
Pathnames imply only an unordered tree. Some visitation ordering must be
imposed on the nodes, and can be remembered in preferences for stability between
runs, independently of accidents of the unspecified sequence of initialization
of file-scope static objects in the various plug-ins. It can be arbitrary --
not constrained to some fixed intrinsic criterion like alphabetical order.
Merging consults the preferences, and also updates them if previously unknown
items are found and inserted. For now, such unknowns just go to the end of
the sequence of siblings, sorted by their path component names.
... 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
... There are now four immediate subclasses (SharedItem and Computed Item,
which are final, and SingleItem and GroupItem, which are abstract), which may
serve future purposes more general than menu items. There are further
subclasses specific to menu management.
The former concrete class GroupItem is renamed TransparentGroupItem.
Also allows direct construction of items in lists from shared pointers.
* Calculate loudness for short or silent selections as well.
In case of selections shorter than 400ms (one momentary loudness block),
take what we have got and divide only be the actual length.
Abort loudness normalization silently if the selected audio is all
silent.
* Fix loudness effect bug when selection includes a gap.
If the selected audio in a track contained a gap between two clips,
an incorrect amount of samples was processed.
