The pin and its position can be set directly from the ruler, which is always visible. Displaying the pin/unpinned state and pin position is probably a bit like displaying the toolbar visibility states and positions in prefs - overload of settings that are easier set another way. I've hidden them for now. We should probably come up with a policy as to what prefs should be shown in prefs and what should not.
MixerBoard, LyricsWindow, Screenshot and most effects are now LTR in RTL locales.
Also added a pref so this can be overridden. As RTL affects window creation, the language choice and this preference may only fully take effect after a restart of Audacity.
This adds a new preference to Playback prefs, VariSpeedPlay, on by default, which makes it possible to vary the playback speed slider whilst audio is playing using play at speed. The code uses the Scrubbing playback engine.
This code is not final, but is already useful. Known issues:
1- Playback does not stop and pop-up the Play at Speed button at the end of playing the selection.
2- The scrub widget shows uselessly on the scrub ruler when in Play at Speed mode and the status bar proclaims 'Scrubbing'.
3- At low speeds the playback is clicky, with VariSpeedPlay, even if no changes to speed are being made.
If we can't fix both 1 and 2 by 2.3.0 release time, VariSpeedPlay will be made false by default.
We were for example getting many of these:
\audacity\src\widgets\numerictextctrl.h(171): warning C4458: declaration of 'value' hides class member
MSVC2013 didn't warn about these, but MSVC2017 does.
This was caused by my commit: f9ee3cdc45ab3c5530505daa119ef01ccfdcc262
When void KeyConfigPrefs::PopulateOrExchange(ShuttleGui & S) is called for the purposes of GetInfo, the pointers to the radio buttons are null, so need to check for this before calls to SetAccessible.
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.
Prefs dialog can now be more compact, but the tree control gains scrollers which look poor. So a height of at least 480px, if no height was set by the user, is used. This way also the key config prefs have reasonable height.
Doesn't set the min size. On small screens, users can scrunch the dialog up tightly if they really want to.
The main change in wxWidgets for the setting of accessibility names is:
7dab555f71 (diff-04f5191d86f95b1c4d5d9c979da65878)
Before this change, with wxUSE_ACCESSIBILITY set to 1, for wxWindow and all the classes derived from it, wxWidgets automatically created accessible objects to handle accessibility itself. Because the way wxWindowAccessible::GetName() was written, the accessibility names of lots of windows and controls had to be set using SetName().
After the change, by default, the accessibility of instances of these classes is handled by Windows. Where the accessibility of a control is handled by Windows, then the accessibility name is automatically set to so the appropriate value. However, an accessible can still be set using SetAccessible() then wxWidgets handles the accessibility for this object.
So for many controls we can just leave Windows to set the accessibility name. However, for controls which don't have any visible labels, or where we want to accessibility name to different from the visible text, then we have to set an accessible object for that control, and then call SetName(). The Class WindowAccessible can be used for this purpose. And for custom widgets, like the TrackPanel, and the NumericTextCtrl, SetAccessible() still has to be called, since they need bespoke accessible objects
So in the cases where we want the accessible name to be different from normal, we now need to explicitly set an accessible object. (Before, this wasn't needed, as accessible objects were automatically created.).
Some notes of the fixes included in this commit:
1. The fixes cover the main window, preferences, and built-in effects. Other fixes will follow.
2. In ShuttleGui, I've set accessible objects for wxTextCtrls and wxSliders. So all of these widgets still need the name set. This was done because there are a lot of instances where these controls need non standard accessibility names, and so it saves having to put lots of SetAccessibles throughout the code.
3. For wxPanel, Windows picks up the accessibility name from the label, and so SetLabel() can be used instead of SetName(). This is just as well, since for windows that contain other windows or controls, setting WindowAccessible as the accessibility object breaks the accessibility tree.
Note that at some stage a lot of calls to SetName() can be removed from the code as they are no longer needed, but it might be better to leave them there for the moment, just in case they are unexpectedly needed.
... Such are not for display to the user. They are appended to menu item
names to identify accelerators, and wxWidgets transforms them appropriately
for the operating system.
Problem: When [gui/shortcuts]fulldefaults is true, then you can't clear the shortcut of a command which is only in the full set.
In bool KeyConfigPrefs::Commit(), for a command only in the full set, dkey = "", so if the key is set to "", there will be no entry in NewKeys for this.
In CommandListEntry *CommandManager::NewIdentifier, if [gui/shortcuts]fulldefaults is true, then for all commands the key is initially set to the default. For the shortcut that should have been cleared, there is no entry in NewKeys to override this, so it is in fact not cleared.
Fix: In bool KeyConfigPrefs::Commit(), when [gui/shortcuts]fulldefaults is true, use the full set of defaults to find the default key.
