Motivation:
1. The text boxes in the label track are not fully accessible for users of screen readers, and I don't think that they can be made to be fully accessible using the accessibility API used by wxWidgets. When such an edit box becomes the focus, this is not announced, and for NVDA users typed characters are not echoed.
2. Provides a work around for bugs 1778 (cannot type diacritics into text label), and 1804 (Windows: Labels do not accept IME (Chinese/Japanese) input).
Fix: Provide an option for a dialog for entering the name. The text box in the dialog is accessible for screen readers. On windows the text box receives wm_keydown and wm_char messages and so is a work around for bug 1804. Being a standard text box, it will presumably be a work around for bug 1778.
1. There is a new option in track behaviors: "Use dialog for the name of new label", which is off by default.
2. When using the commands "Add label at selection" and "Add label at playback position", when the dialog closes, focus is returned to the track which was the focus before the dialog opened. I think this is more convenient for users of screen readers.
This is a squash of 50 commits.
This merges the capabilities of BatchCommands and Effects using a new
AudacityCommand class. AudacityCommand provides one function to specify the
parameters, and then we leverage that one function in automation, whether by chains,
mod-script-pipe or (future) Nyquist.
- Now have AudacityCommand which is using the same mechanism as Effect
- Has configurable parameters
- Has data-entry GUI (built using shuttle GUI)
- Registers with PluginManager.
- Menu commands now provided in chains, and to python batch.
- Tested with Zoom Toggle.
- ShuttleParams now can set, get, set defaults, validate and specify
the parameters.
- Bugfix: Don't overwrite values with defaults first time out.
- Add DefineParams function for all built-in effects.
- Extend CommandContext to carry output channels for results.
We abuse EffectsManager. It handles both Effects and
AudacityCommands now. In time an Effect should become a special case of
AudacityCommand and we'll split and rename the EffectManager class.
- Don't use 'default' as a parameter name.
- Massive renaming for CommandDefinitionInterface
- EffectIdentInterface becomes EffectDefinitionInterface
- EffectAutomationParameters becomes CommandAutomationParameters
- PluginType is now a bit field.
This way we can search for related types at the same time.
- Most old batch commands made into AudacityCommands.
The ones that weren't are for a reason. They are used by mod-script-pipe
to carry commands and responses across from a non-GUI thread to the GUI
thread.
- Major tidy up of ScreenshotCommand
- Reworking of SelectCommand
- GetPreferenceCommand and SetPreferenceCommand
- GetTrackInfo and SetTrackInfo
- GetInfoCommand
- Help, Open, Save, Import and Export commands.
- Removed obsolete commands ExecMenu, GetProjectInfo and SetProjectInfo
which are now better handled by other commands.
- JSONify "GetInfo: Commands" output, i.e. commas in the right places.
- General work on better Doxygen.
- Lyrics -> LyricsPanel
- Meter -> MeterPanel
- Updated Linux makefile.
- Scripting commands added into Extra menu.
- Distinct names for previously duplicated find-clipping parameters.
- Fixed longstanding error with erroneous status field number which
previously caused an ASSERT in debug.
- Sensible formatting of numbers in Chains, 0.1 not 0.1000000000137
... Maybe a good feature idea, but the implementation pollutes the code in
too many places.
It's a special case of the more general idea of many-to-one associations
between screen rectangles and track objects. More generalized ways to
accommodate that should be sought.
- AutomationCommands replaces GetAllMenuCommands, and can provide
information about menus, buttons and toolbars to a script.
- BatchCommands can now return textual results to a script.
- There's a new GUID for mod-script-pipe and it is included in the .sln.
... As they did with Ctrl+Shift+F, with a certain minimimum number of wave
tracks that depends on screen resolution. On my Macbook, that was 13 tracks.
This bug was a consequence of James' TCP layout changes making buttons a little
taller plus my changes to hide any top controls for which there is not
sufficient height.
The fix makes the height of tracks after Ctrl+Shift+F a bit more (44 pixels
not 40) than in 2.1.3.
This fix also replaces some more "magic numbers" with calculation from
tabled data about TCP layout.
... Because all hit tests returned all fields blank, or else, returned a
UIHandle object whose Preview method gives the rest of the information; so
the other fields were redundant.
Call HitTest in just one place
Can now preserve repeatedly hit UIHandle objects during pre-click motion
Fields of HitTestResult besides the handle pointer are now unused
The need to repaint a track during mouse movement can be indicated when
constructing a UIHandle or when updating it for move; HitPreview no longer
does this
And the last allows simplifications of LabelTrack glyph highlighting
Also move the temporary state for label glyph dragging out of LabelTrack
... Rather, construct them during hit tests (also capturing more state sooner
rather than at Click time, and adding some accessors for later use)
This also fixes bug 1677 by other means and avoids similar problems.
A cell may be implemented to re-use a previously hit handle object, not yet
clicked, in a later hit test, by remembering a weak pointer, but TrackPanel
holds the strong pointers that determine when the object is destroyed.
And the objects will surely be destroyed after drag-release, or ESC key.
For now they are also destroyed whenever not dragging, and hit-testing is
re-invoked; that will be changed later, so that the re-use mentioned above
becomes effective, but still they will be destroyed when the pointer moves
from one cell to another.
... Let cell hit tests, and handle preview, know states only, not transitions.
Cell hit tests are passed a mouse state that does not always match the current,
but anticipates the button click to come; usually left, but if the Control
[sic] key on Mac is down, then right.
Thus, pressing and releasing Mac Control in multi-tool switches in and out of
the magnifier cursor.
... in cases such as: dragging an envelope point, then hitting space to play,
which forces the drag to finish early. If you move the mouse, cursor will
remain "ban", even while the mouse button remains down but no drag is really
happening.
