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.
... 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
... See ultimate origin of some of the deleted lines at 4724c6a
Whatever change it is that needs loading by LoadPrefs -- do it instead right
after any possibility of changes to the relevant preferences, in the Commit()
functions of SpectrumPrefs and WaveforPrefs
... and you press Preview in Spectrogram preferences.
And complete null checks on GetActiveProject calls in src/prefs.
And in fact, don't even show the useless Preview button when there is no
project.
... 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.
