Bugzilla – Bug 679
Incorrect keyboard preferences for "Snap To"
Last modified: 2018-08-20 11:45:36 UTC
Created attachment 435 [details] Update "Snap To" keyboard preferences. "Snap To" has been upgraded to support snapping to nearest or previous snap position, but the Keyboard Preferences have not been updated and still has the options "On or Off" rather than the new "Off / Nearest / Prior".
Thanks, Steve. Tested on Windows. Marked the bug as P2 since we'll want to have the new Snap To choice in "Changes since" in the Release Notes, and we'll want an easy way to change the Snap To choice now that it's harder to change it using the mouse. One disbenefit found - users who had a shortcut for Snap To On in 2.0.5 will now find it doesn't work .Can anything be done about that? The function that does Snap to Nearest is actually the same as Snap to On, isn't it - because Snap to On and Snap to Nearest in .cfg are both value=1. I note that a focused track is needed for the shortcuts to work, hence if you change the Snap To action with the mouse then the shortcuts don't work. Unless anyone wants to discuss what the behaviour should be on -quality, I think that should be a new bug that no track is required for these shortcuts to work.
(In reply to comment #1) "I think that should be a new bug that no track is required for these shortcuts to work." I agree - especially since you can operate the Snap To drop-down directly with no track present.
(In reply to comment #2) If we want these keyboard shortcuts "always enabled", then it is a simple fix, but a patch for it will clash with this patch. As this is P2 then I suggest that this is marled patch_ready. When bug 679 is resolved I can post a patch for this other issue (assuming that -quality agree that it needs fixing).
Created attachment 436 [details] Always allow changing SnapTo Apply Steve's patch first, and then apply this one. Let me know if it doesn't resolve all of the issues.
(In reply to comment #1) > One disbenefit found - users who had a shortcut for Snap To On in 2.0.5 will > now find it doesn't work .Can anything be done about that? The function that > does Snap to Nearest is actually the same as Snap to On, isn't it - because > Snap to On and Snap to Nearest in .cfg are both value=1. > No real good way to fix this. The original "SnapToOn" could be left in which would function like SnapToNearest, but that might be confusing.
(In reply to comment #4) Patch "Always allow changing SnapTo" That's the same as I sent for QA to try. Looks good here (Linux). (In reply to comment #5) In older versions, SnapTo=1 would be either "Nearest" or "Prior" depending on which version of Audacity was used to create the preference. If we hacked it so that the old "SnapToOn" binding now worked as "SnapToNearest" it would be even more confusing for users that set a shortcut when "On" meant "Prior". Less confusing to leave it as it is I think.
Tested both patches on Windows and Mac successfully. "Patch_ready" marked, meaning on "Update "Snap To" keyboard preferences" id=435 AND "Always allow changing SnapTo" id=436. Please apply id=435 first, then id=436. (I can't put id numbers in the "Keywords" box, sorry). (In reply to comment #6) > Steve wrote: > In older versions, SnapTo=1 would be either "Nearest" or "Prior" > depending on which version of Audacity was used to create the preference. > > If we hacked it so that the old "SnapToOn" binding now worked as > "SnapToNearest" it would be even more confusing for users that set > a shortcut when "On" meant "Prior". Less confusing to leave it as > it is I think. Yes the Luddites still on older 1.3 would still have to lose their Snap To On (meaning "Prior") shortcut and the name in Keyboard Prefs would have to show as e.g. "Snap To On (Nearest)". I agree it's more confusing than it's worth so I'll just mention the loss of the Snap to On shortcut in "Changes since".
Leland committed "Update "Snap To" keyboard preferences" id=435 and "Always allow changing SnapTo" id=436 in r12918.
I confirmed fix on Mac too.
