The name comes after the checkbox, and looks better without the ':'.
Made an exception for "Resize:" in SetProjectCommand.
It controls 4 subordinate settings, and those settings do come after the name.
Problem:
If a new version of Audacity introduces a new default shortcut, or changes an existing one, then this may be the same shortcut as a user has previously assigned to another command. Both commands will have the same shortcut, and the shortcut will only execute one of those commands.
Fix:
Check for any such duplicates when a user opens a version of audacity using an audacity.cfg file which was created with a different version.
For each duplicate found, remove the shortcut from the command which has a new or changed default.
If duplicates where found, open a message box informing the user of the removed shortcuts.
... such as Nyquist Workbench.
I don't fully understand why, but destroying the menu registry items very late,
during the destruction of static objects, causes a crash in memory deallocation,
at least on Mac.
So destroy the menu registry explicitly in application shut-down.
... 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.
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.
... 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.
... 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.
... 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.
... in Wave track context menu and SetTrackVisualsCommand
Instead, discover them through a registry.
This eliminates some duplication of string constants and prepares for
non-intrusive generalization to more kinds of sub-views.
This makes the command agnostic about which subview types are known, but the
context menu still has special case treatment for Spectrogram Settings and
Wave Colors.
