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.
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. ;-))
This is part 1...
Provides some relief to the selection "hang"
This patch adds the ability for the keyboard based commands (like cursor left,
extend selection right, etc.) to know when the key has been released.
When the patch is applied the current state is saved only when the key is
released and not every time it repeats.
Here's an example of the difference it makes.
This video show the selection "hang", but also watch the CPU usage. All I'm
doing is pressing SHIFT+RIGHT ARROW.
http://youtu.be/tdMntDwGSkM
This one is the same thing bug with the patch applied. Notice that the
selection "hang" no longer occurs and look at the CPU usage!
http://youtu.be/EpXNsQ4Cky0
research into why that code had been ifdef'd in the first place and allowed
the root cause to be identified.
Now the menus are cleaned up properly, which also fixes bug #458 without
having the workaround in r12639.
Basically, the problem was that attempts were being made to manipulate
menuitems on a menu that no longer existed (after the menus were rebuilt).
One tricky aspect was that until GetActiveProject() is ready to return non-NULL, ControlToolBar::RegenerateToolsTooltips() cannot get the project's CommandManager, so cannot get the shortcuts. Changed ControlToolBar::RegenerateToolsTooltips() to be public and now call it late in wAudacityProject(). When called before the project is completely instantiated, in the rewritten ControlToolBar::RegenerateToolsTooltips(), it just sets the tooltips to the names without the keys, pretty much as now -- but I don't think users will ever see that because of the subsequent call.
Anyway, did it in a more programmatic way than the previous code, which reduces string literals duplication.
Btw, I changed the start value for the ID_PLAY_BUTTON because the former value of 0 causes FindWindow() to return the toolbar rather than the button -- wxWidgets bug.
Also got rid of some cruft and applied a few WXUNUSED.
