... except Audacity.h
This forces us to make each header contain all forward declarations or nested
headers that it requires, rather than depend on context.
... which will make it easier to change the types of those containers to
std::vectors of other string-like classes
for wxString,
IsEmpty => empty
Clear => clear
Alloc => reserve
for wxArrayString,
Count => size
GetCount => size
IsEmpty => empty
Add => push_back
Clear => clear
Empty => clear
Sort => std::sort (only with default comparator)
SetCount => resize
Last => back
Item => operator []
Alloc => reserve
This revised fix:
- No longer attempts to drive "Default sample rate" from the selection toolbar.
- No longer drives 'Project rate' direct from prefs. It's usual it comes from the project.
- Instead 'Project rate' in the project might change if 'Default sample rate' pref is updated, but ONLY if the project has no tracks.
- When 'Project rate' in the project is updated, that is now always signaled to the selection toolbar. Previously it wasn't.
The Project Rate in the Selection Toolbar and in the Preferences dialog are now the same thing. They ALMOST were before, causing confusion, and this bug.
This means that the fancy mechanism to set 'other' rates in Preferences is moot, since the Selection Toolbar bar does not have that option. 49000 will be overridden by 48000 for example.
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.
... and similar wx "variadics," which all treat wxString smartly enough that
you don't need this.
Don't need c_str either to convert wxString to const wxChar * because
wxString has a conversion operator that does the same.
- Dead code from experiments in SelectionBar removed.
- Many warnings about unused parameters fixed with WXUNUSED()
- Many warnings about signed / unsigned comparisons cleaned up.
- Several 'local variable declared but not used' warnings fixed.
Problem was that on mac enable/disable clears the colour back to black.
The easiest workaround was to create a new class auStaticText that does all that we
need for wxStaticText.
Problem: When selection details set to start and end in selection bar, start cannot be increased higher than end, and end cannot be decreased to be less than start. These restrictions are not present in previous versions of Audacity, and are not desirable.
Fixed.
Problem: If the accessibility name of a control is empty, Jaws may use nearly text for the name - in this case Audio position.
Fix: Set the accessibility name to "\a".
The layout of SelectionToolbar and SpectralSelction Tollbar now match, and they can be placed nicely side by side.
The borders around controls have been tweaked.
Extra vertical spacer lines have been added into the title row.
I've deliberately not given the choice a title, and deliberately put the word 'selection' at the end, so as to be better/faster for Screen Reader users.
The look of Selection Toolbar and Spectral Selection Toolbar is now consistent. In dark themes both could have better looking choice boxes.
Tooltips tell users what the abbreviated names in the radio button group mean. The hyphen helps a little in relating the title , which has a hyphen in it, to the two fields.
Fortunately a vertical line works just as well as a checkbox in working around the bug where radio buttons change to the first field. It is better for screen readers too as it is not included in the tab order.
The checkbox on the selection toolbar is a temporary work around for a bug in windows with tabbing. Tabbing into a radio button will set the first item of the radio button group without it. Still looking for a better workaround.
This is a convenience for sighted users. If they are showing start, center, length, end, they can click on the title 'Center' to preserve it, and then modify length. Similarly for the other controls. This makes working with more than two controls much more intuitive.
The toolbar can now show subsets of the start, center, length and end numeric controls. The choice is made using a button with a pop-up menu. The two most recently modified controls 'drive' the other two, whether they are visible or not. If shown, the driven controls are indicated in the name above (also for screen readers).
Most users will opt to just show two of the controls, e.g. start and end.
The menu button (Classic theme) has three dots on it. Other themes don't yet have the icon and will show as black.
For Light and Classic themes that use black text, we'll use the length/end buttons because Windows uses black for text.
For Dark and HiContrast themes that use a light colour for text, we'll use the length/end buttons IF the OS is set to use the exact same colour for text.
That for example happens if we use Microsoft's HiContrast2 and our HiContrast theme.
If the OS and theme text colour differ, then if we set blend theme colours option, which is the default, we might still use the OS colour for text in Audacity. That will happen if the OS colour has decent contrast to our theme's background colour. Decent is defined as more than 250 difference in RGB values. If we use the OS colour for text, then we get the proper length/end buttons.
Note that this adds a new feature to the theme blending, in that the text colour will often adapt. Useful when using custom text colours with HiContrast2. When the text colour adapts, we will continue to get proper length/end buttons.
Advice to users is to match OS and Audacity themes, and use the blend option. When themes don't match, it may be desirable to disable blending.
They had lost the focus/voice-over functionality because I added code to draw them in the
theme colour. Now I disable that code, IF recolouring is both set and active. This will happen
for example, if Hi-Contrast is used with the Hi-Contrast system theme.
... A non-narrowing conversion out to long long is a necessity, but the
conversions to float and double are simply conveniences.
Conversion from floating is explicit, to avoid unintended consequences with
arithmetic operators, when later sampleCount ceases to be an alias for an
integral type.
Some conversions are not made explicit, where I expect to change the type of
the variable later to have mere size_t width.
