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.
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.
Posterisation was caused by having a bright theme cache and using a darker theme (in linux) so the light colours 'got stretched' and showed up the relatively few distinct values there. So the Classic theme is now darker, and we expect (on Windows) that it will be recoloured to windows lighter colours.
