... 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.
