Bugzilla – Bug 307
SHIFT key makes Play button display as Loop Play
Last modified: 2018-08-20 11:45:28 UTC
In general, any pressing of the SHIFT key will cause the Play button to become the Loop Play button until the SHIFT key is released, this may or may not be good. In the case where the shortcut opens the Import file dialog (maybe elsewhere) when the dialog returns the Loop Play button remains displayed but playing does not loop.
Not a regression, even on 1.2.6. Merely holding SHIFT changes Play button to Loop Play, but in most cases releasing SHIFT immediately reverts the button to standard play e.g. CTRL + SHIFT + C. CTRL + SHIFT + I seems to be a case where Play button does not revert until activated by Space, or hovered over. After import you can still use SHIFT + Space to loop play, so I think P5 is correct. Even if I change the Loop Play binding to something not including SHIFT, SHIFT still changes the Play button. I assume it affects Mac too, but no reports yet.
(In reply to comment #1) Debugged this for the Ctrl+Shift+I case. In that case, none of Audacity's key-up event handlers get called. I think the key-up event gets swallowed by the "Select one or more audio files..." window. In reviewing menu commands, I think this can happens *only* for Ctrl+Shift+I currently, so I made the fix in AudacityProject::OnImport(). Good reason to keep Shift out of the default keyboard shortcuts for commands that bring up wxWidgets windows. At revision: 12439
(In reply to comment #2) > Debugged this for the Ctrl+Shift+I case. In that case, none of Audacity's > key-up event handlers get called. I think the key-up event gets swallowed by > the "Select one or more audio files..." window. To be sure to be clear, I consider that a wxWidgets bug.
(In reply to comment #2) Vaughan wrote: > In reviewing menu commands, I think this can happens *only* for Ctrl+Shift+I The same issue occurs when using the keyboard shortcut for: "Export" (Ctrl+Shift+E), "Export Multiple" (Ctrl+Shift+L), "Open track drop down menu" (Shift +M), and can also occur with custom shortcuts that open dialogues (for example if you set "Alt+Shift+M" to open the Metadata Editor). I've set the status to reopened. I'm still not persuaded that using a modifier key on its own to trigger something is a good idea. Even if we fix it in all the current places that the problem can currently occur, the problem is still waiting to appear again in the future when an unwary developer introduces a new feature.
better fix in r12441 that prevents "problem is still waiting to appear again in the future when an unwary developer introduces a new feature" and custom key bindings that have shift and bring up a dialog
(In reply to comment #5) Cool, that works.
RESOLVED-FIXED. Vaughan's fixes have by consensus done enough to resolve this bug as stated. There is a bug 643 for agreed residual issues to make the behaviour more consistent.
