It's now in recording-prefs rather than track-behavior-prefs, and to make room latency options (which are related to device) ar enow in device-prefs. Naming of new tracks has also been made slightly more compact.
This attempted fix applies the 'space' trick to make accelerators invalid, so "Left" is added as " Left" into the menus, and appears normal but does not act as an accelerator. This is now only done for the problematic accelerators rather than for all accelerators. It's believed that doing it for all accelerators caused the problem.
In debug builds users will see messages like the one below in the console:
"Unrecognized accel key ' right', accel string ignored."
This fix additionally adds 0..9 to the specially handled accelerators. This should address:
Bug 1260 - Cant type "1" in the Project Rate text box
The fix has been developed and tested on Window only. Theoretically the space might cause problems on Mac and if it does the 'space' trick could be applied just on Windows and Linux, since Mac did not seem to have the problem reported in 1260.
Adding an orange border around the images in a theme makes it much easier to cut and paste in the correct position. I've also expanded the internal images and fixed up a few image details - the pins/bobbins on darker themes, and the light blue rather than dark blue for negative times.
This progresses this bug. Specifically on Windows, Left and Right arrows and Enter (non keypad version) should now no longer be a problem. The fix is to not show these shortcuts in menus, because otherwise the menus will catch the events. Unfortunately attempts to show these specific shortcuts in the menus bring back the bug.
Steps to reproduce for 1637 will need to be updated.
The image cache that users work with should now have 'pixels' that are 4x4. This will in time allow us to have large or small versions of all buttons, and also means we have hi resolution images for HiDPI screens. The actual cost of the extra size should be small, as compression will see lots of repetition.
The main point of doing this now is so that new contributed themes can be HiDPI from the start.
The time ruler previously used blue for negative numbers, when scrolling left of zero was enabled. This was broken by adding the dark-theme code. Fixed now, and with a new configurable colour for it which defaults to blue if non provided.
As mentioned by PRL
(https://sourceforge.net/p/audacity/mailman/message/35763043/),
WarpAndTransposeNotes didn't transpose, but _did_ wrap, notes that were on
channels that were hidden. This behavior is inconsistent with all other
operations, and thus has been changed to always transform and wrap
regardless of visibility.
Additionally, fix the UI portions of these, and fix Trim for note tracks
(the code already existed, but due to flags would not work). As PRL
requested, this is gated only behind USE_MIDI.
It's no longer used, and the new set up for MixerTrackCluster makes them
unable to change the type of the slider (so it should also no longer need
to be used).
This reintroduces the buttons to toggle display of individual midi
channels, and cleans up the code behind that feature.
This functionality has actually been present in production versions of
audacity for a while, at least for clicking. However, the buttons
themselves were not drawn, making it exteremly painful (but possible) to
use.
As requested by PRL, this is always enabled if USE_MIDI is defined.
This fix works by detecting whether the focus window is the TrackPanel, in which case all keys are handled normally. If it isn't the TrackPanel, then the problematic keys do not get sent to our own CommandHandler and proceed on to wxWidgets.
A problem that then follows is that the menu accelerators (which normally don't get a look in) may then convert the event to a menu event and stop it going any further.So it does not get to the focus window.
The fix/workaround for that is to NOT provide accelerators for up, down, left and right arrow in the menus. I'd much rather be able to turn off those accelerators completely, yet still show them to users as hints.
The fix was regarded as a workaround, and too draconian. The problem is that Left and Right shortcuts are being captured (somehow) by our CommandManager when navigating in docked toolbars. A full and proper fix rather than not binding these shortcuts would apply them to the toolbar in preference to the CommandManager, and so fix bug 1637, which Bug 1639 has now been marked as a duplicate of.
Previously, these two commands used the clips in the focused track. They now have similar to the Tracks->Pan->Left/Right/Center commands. That is if any audio tracks are selected, the clips in these tracks are used, otherwise the clips in all audio tracks are used.
This update affects the four commands:
Cursor to Previous clip boundary
Cursor to Next clip boundary
Select previous clip boundary to cursor
Select cursor to next clip boundary
Previously these commands all used the clips in the focused track. This update changes this so that their behaviour is the same as the Tracks->Pan->Left/Right/Center commands. That is, if any audio tracks are selected, all the clips in these tracks are used, else the clips in all audio tracks are used.
Provides a clear boundary between scrub ruler and quick select ruler, even if the theme colours have been warped to be very similar.
Thanks to Gale for spotting this problem on Mac.
I've bound the commands that use Left and Right keys to use Ctrl-Left and Ctrl-Right instead. I did not find a simple fix that allowed docked toolbars to get 'furst dibs' and take left and right keys if they wanted them.
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.
