... for functions in final classes.
override is like const -- it's not necessary, but it helps the compiler to
catch mistakes.
There may be some overriding functions not explicitly declared virtual and I did
not identify such cases, in which I might also add override.
... Should have no effect on generated code, except perhaps some slight faster
virtual function calls. Mostly useful as documentation of design intent.
Tried to mark every one of our classes that inherits from another, or is a
base for others, or has abstract virtual functions, and a few others besides.
In the class CommandListEntry, the default key was being set to an empty string, rather than the correct key.
This resulted in bugs such as: pressing default in keyboard preferences clearing all the shortcuts, entries
being created in audacity.cfg for all commands with keystrokes, and ending up with commands with the same shortcut.
David has been trying to beat it into my thick skull that the
command manager should use the system created key up event rather
than generating it, but I just wasn't getting it.
Actually, the documentation for the OSX method I needed to use
to get at the key event before the menus did said that a key up
event couldn't be captured on 10.6 (the oldest we support). But,
testing showed that it can be, so I was able to do what David was
suggesting.
I'm pretty sure this gets all of the currently known issues, including
the SHIFT+M not working, the Play buttons responding to SHIFT and CTRL,
the ESC key canceling drags, and I'm pretty sure it even fixes
but #784.
Several other issues were also fixed (hopefully ;-)).
This is a major change to accelerator handling and keyboard
capturing. Menu shortcuts, non-menu commands, label editing,
navigation, and basically anything else were you might use
the keyboard should be thoroughly tested.
It had been causing problems in Unity for a while now and they
were missing on OSX as well in wx3. So, the old menu Open/Close
method of hiding has been removed and replaced with an event
filter/monitor which looks for wxEVT_CHAR_HOOK events to pass
key events to the handler that has the keyboard captured.
This brings the builtin, LV2, and VAMP effects inline with the
Audio Units, LADSPA, and VST effects. All effects now share
a common UI.
This gives all effects (though not implemented for all):
User and factory preset capability
Preset import/export capability
Shared or private configuration options
Builtin effects can now be migrated to RTP, depending on algorithm.
LV2 effects now support graphical interfaces if the plugin supplies one.
Nyquist prompt enhanced to provide some features of the Nyquist Workbench.
It may not look like it, but this was a LOT of work, so trust me, there
WILL be problems and everything effect related should be suspect. Keep
a sharp eye (or two) open.
If you can believe it, this whole big mess is
just to get localized effect labels back into
the menus.
I sure wish I'd had a little bit more time to
finish up all of the effects. It sure would
be a lot cleaner (code wise).
I'm 100% certain I found the cause this time (r13739 was
still needed though).
There's a design flaw in wxMenuBar::RebuildAccelTable() that
will always leave the last accelerator active as they are
removed from the menus.
For the Edit menu, that will be "Move Cursor -> to Track End"
because of the way the submenus are traversed. And because that
fella happens to have an unmodified character for an accelerator
it can't be used in a label track until another menu is opened
and closed.
The workaround is to nullify the accelerator table when a menu
closes.
Whenever a menu is NOT open, the accelerator keys are
stripped from the menu items so that the O/S doesn't even
know that accelerators are being used (we do it internally).
While this stripping was being down when the menus are set
up, it was NOT being down when the Undo and Redo menu items
were modified to include the "last action".
So, the fix is to strip the accelerator then as well.
Removed a line in AddItem() and InsertItem() that didn't
seem to make sense (especially given the comment). However,
it caused an issue where the key assignment would persist
for one last time after leaving Preferences. It would then
act as desired.
This MUST be tested by everyone on as many platforms as you
have access to...reason:
This removes a very old piece of code (May 10, 2003) in the
command manager that worked around a problem in GTK where
accelerators could not be changed again after the initial
menu setup.
While there is another way to fix this bug, remove this old
code is actually a better way AS LONG AS it doesn't break
anything else. So far, it's looking like it is no longer
needed.
But, I'll be trying as many combinations of changing shortcuts,
entering/exiting preferences, swapping shortcuts, etc, as
I can on Linux, Windows and OSX.
But, the more ppl trying to break keyboard shortcuts the
better.
In case it helps, here's the comments that Dominic had in the
code:
// This is a very weird hack. Under GTK, menu labels are totally
// linked to accelerators the first time you create a menu item
// with that label and can't be changed. This causes all sorts of
// problems. As a workaround, we create each menu item with a
// made-up name (just an ID number string) but with the accelerator
// we want, then immediately change the label to the correct string.
// -DMM
