... the intention being, that no string literal for a path, or its default
value, shall ever occur twice in the code, relying on long-distance coincidence
of literal values. Instead, a named Setting object is constructed once, then
read and written.
For now, the Tie... functions in ShuttleGuiBase will take references to
implicitly constructed temporary Setting objects. But all should later be
made static objects, and the constructors made explicit.
... This makes it impossible to forget to include the EXPERIMENTAL definitions
(such as when cutting and pasting code) and so get unintended quiet changes of
behavior.
The EXPERIMENTAL flags are now specified instead in new file Experimental.cmake
Completing the update by John Colket. The plan always was that
these new 'repeat' entries were optional commands bindable to
keyboard shortcuts by advanced users.
Users visiting the menus can re-select the item they want.
For these menu users it would be confusing/overload to list
these repeat commands in the menu. Repeat last effect in the Effects
menu is more important. It is there in the menu to signal to
users that there is the Ctrl+R key binding for 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
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.
... 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.
... in cases of "TranslatableString" that are not really translated.
This makes it easier to scan the code for such unusual constructions of
TranslatableString, distinct from mere mentions of the TranslatableString type.
... Because label wasn't used when reading back, and it was, questionably,
writing localized strings out.
CommandManager serialization is used only for exporting and importing keystroke
shortcuts, and not in save and load of projects.
There was apparently confusion too about tab characters separating command name
from a menu accelerator, but such are not stored in the label field of
CommandListEntry. Those tabs were only added by certain accessor functions,
which are here renamed.
... and deduce whether to exclude from macros inside NewIdentifier, simplifying
argument lists further
Also fix the localization of "..." added to names by PluginMenus.cpp
... The purpose of the boolean field in command entries was to exclude certain
menu commands from being steps in macros, because they require user interaction.
Effects are never meant to be excluded, even though they normally have dialogs,
but in the context of macro execution, the parameters are supplied by other
means.
... This capability was unused. The only uses of item lists are in
TrackMenus.cpp, for aligning tracks.
The parsing of a translated string for encoded infomration was questionable.
... which I think was only meant to define a precompiled header for speed on
Windows, and is not necessary for compilation. It is not included in many
other places.
The result is to shrink the big s.c.c. from 44 to 38. Five files remain in
a new small component:
CommandManager
Menus
ToolBar
ToolDock
ToolManager
The sixth freed file is AudacityHeaders itself.
... In fact it was only ever different from flags when flags had the special
NoAutoSelect and mask did not. Now put that bit in the mask too, and make
the special NoAutoSelect always true in MenuManager::GetUpdateFlags(). This
still preserves the intended effects of NoAutoSelect.
Paul Licameli
James Crook
JohnColket
luzpaz
Leland Lucius
freddii
Yuri Chornoivan
David Bailes
Binary Wisdom