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
With realtime preview, the keyboard user will need this to get
back and forth between the effect and the project window. Actualy,
the "problem" existed before this since the keyboard user couldn't
switch between project and Plot Spectrum windows.
The normal flags-based keyboard handling would not work since it
depends on the state of the project and requires a project window
to have the current focus.
In this new case, a modeless dialog may actually have the focus and
using the "switch window" key combo may happen in nearly any mode, like
while playing.
So, I "created" the concept of "meta" commands...ones that do not have
the restrictions mentioned above. The should be used sparingly and
you must be careful about what happens within their handlers.
Correct string formatting for:
2/15 %d + enum => %d + int
3/15 %lld + int64_t => %lld + long long
4/15 %d + int64_t => %lld + long long
5/15 %d + double => %f + double
6/15 %d + int32_t => %d + int
7/15 %d + intptr_t => %p + void*
8/15 gint, guint
9/15 %d + long => %ld + long
10/15 %n + int => %d + int
11/15 %x + int => %x + unsigned int
12/15 %f + int => %d + int
13/15 %S + wxChar* => %s + wxChar*
14/15 %d + size_t => %d + int
15/15 %d + size_t => %lld + long long
"The functions wxString::Format, wxString::Printf (and others indirectly) have become stricter about parameter types that don't match (format specifier vs. function parameters). So the bugs (that were already present in audacity before) become visible in wx3.0 as error message dialogs. I've checked all occurrences of Printf, wxPrintf, PrintfV, Format, FormatV, wxLogDebug and wxLogError systematically and made the type match."
Note (9/15): In TrackPanel.cpp, ExportMP2.cpp and CompareAudioCommand.cpp this patch supersedes related change done in r13466 because the new solution requires fewer casts and therefore simplifies the code.
Note: Many .po files are affected, and we need to be very careful about this. Incorrect "%d" and similar in translation files may lead to crashes in those languages (only). This is something we should actually have been more careful about in the past. We need to write a script to check that the "%d" and similar format specifiers match between English and translation.
I've made it where you can enable and disable via experimentals:
EXPERIMENTAL_REALTIME_EFFECTS
EXPERIMENTAL_EFFECTS_RACK
You will notice that, as of now, the only effects currently set up for
realtime are VSTs. Now that this is in, I will start converting the
rest.
As I start to convert the effects, the astute of you may notice that
they no longer directly access tracks or any "internal" Audacity
objects. This isolates the effects from changes in Audacity and makes
it much easier to add new ones.
Anyway, all 3 platforms can now display VST effects in graphical mode.
Yes, that means Linux too. There are quite a few VSTs for Linux if
you search for them.
The so-called "rack" definitely needs some discussion, work, and attention
from someone much better at graphics than me. I'm not really sure it should
stay in as-is. I'd originally planned for it to be simply a utility window
where you can store your (preconfigured) favorite effects. It should probably
revert back to that idea.
You may notice that this DOES include the API work I did. The realtime effects
were too tied to it and I didn't want to redo the whole thing. As I mentioned
elsewhere, the API stuff may or may not be very future proof.
So, let the critter complaints commence. I absolute KNOW there will be some.
(I know I'll be hearing from the Linux peeps pretty darn quickly. ;-))
He wanted to help so I asked if he wanted to track them down. He agreed and
found more than I probably would have. And he said there were more, but the
rest were questionable and since he works on Windows, wasn't able to actually
test.
I give a few of the ones he did find a go and they do indeed get rid of the
assertions.
(Basically, a 64-bit/32-bit issue, easily resolved with a typecast.)
This relies on three new nyquist scripts to actually do the editing. The peak-snapping code in FrequencyWindow has been extracted into a new class, SpectrumAnalyst, to provide peak-snapping in spectrogram too.
We can't go to 3.0.1 yet as there are still build issues on
Linux and OSX. You can get Windows to build, but there's
still some display issues.
These changes should work with wxWidgets 2.8.12 as well, so
we can take our time to get things working properly before
switching over.
This change is believed to be a direct refactoring that does not change functionality. It paves the way for more complex kinds of selection, such as selections involving frequency as well as time. It also reduces risk of left and right edges being swapped in future code using SelectedRegion, as the default is to swap on assignment if needed.
