Problem: When [gui/shortcuts]fulldefaults is true, then you can't clear the shortcut of a command which is only in the full set.
In bool KeyConfigPrefs::Commit(), for a command only in the full set, dkey = "", so if the key is set to "", there will be no entry in NewKeys for this.
In CommandListEntry *CommandManager::NewIdentifier, if [gui/shortcuts]fulldefaults is true, then for all commands the key is initially set to the default. For the shortcut that should have been cleared, there is no entry in NewKeys to override this, so it is in fact not cleared.
Fix: In bool KeyConfigPrefs::Commit(), when [gui/shortcuts]fulldefaults is true, use the full set of defaults to find the default key.
Defaulted move constructors and assignments introduced at 080dd34 are not
essential but might give a bit more efficiency in std::vector on non-Windows.
Previous compilation fix was incorrect! Excpliticly defined move assignments
should not have had no-effect bodies!
... and the distinction makes a difference only for built-in effects.
"Id" is meant to persist in pluginregistry.cfg, and is constrained by how
previous versions of Audacity were written.
"Name" is not persistent, so we have the liberty to change it, as done here
for the built-ins.
... though harmlessly so. They called to nonstatic member functions of classes
with improper this pointers; though the functions did not use this.
Bind events to nonmember funtions instead. Sometimes just to empty lambdas to
consume the event and ignore it, blocking other handlers.
... it's either the source of the connection that is being destroyed, or other
object (such as an ancestor window) transitively owning it and so causing it to
be destroyed too;
or, the sink is being destroyed, and that sink is a wxEvtHandler (which is
always so for Disconnect, though not for Unbind in case Bind was passed a
member function of a non-wxEvtHandler).
wxWidgets takes care of erasing the connection in such cases.
This removes most calls to Disconnect and Unbind. Many destructors shrank to
nothing.
Notably, in case of popup menu handling, the call to Disconnect is not removable
because the object being destroyed is neither the source nor the sink.
... in case you also do things, concurrent with the recording, that affect the
undo stack, either by pushing it (such as by changing the gain on one of the
playing tracks, or making a label) or by "Modifying state" without a new undo
item (such as when you change its size or mute or solo).
... But perhaps we are developing the means to relax even this ban safely.
For instance, why not undo a mistaken AddLabelPlaying command (Ctrl+M) without
stopping the recording?
... Vacuous pushes should not happen yet, but may happen after the machinery
for pending track changes is added and used.
This will only detect the case of one new recording track being modified. It
will not detect it if that track is modified, but other tracks exist that are
not modified.
