* Eliminate ModuleManagerInterface...
... It was there only to provide RegisterModule(), but that was not used
anywhere. So simplify.
* Remove nested #include of ModuleInterface.h
... Require the declarations to be in .h files, to be sure graph.pl detects the
dependencies.
Only one more #include was needed in Nyquist.cpp. This doesn't reveal any
more hidden cycles.
... They are not necessary to build, but the do indicate some link
dependencies to fix, that were not shown in results of scripts/graph.pl.
The link dependencies exist because the header declaring some name did not
correspond to the .cpp file that defined it.
... also restore the intended meaning of "allowDup" (for debugging checks only),
which had never been properly implemented because the label, not the
accelerator, was scanned for it; see commit f2f7568
... 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.
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.
