3.4 Beta - Reset position (slur) after editing
Nice implementation of not requiring additional steps to edit a slur and allowing for [next/previous element] commands. After testing this, there is one thing found that needs some fixing:
1) Slur between two notes
2) Select and move the slur in some way
3) Now while in editing mode, we're allowed to reset via the default [ctrl+r] [reset] command
Notice that the positioning of the editing nodes/skeleton stays where the motion was located, and doesn't move, but it will be updated upon the next edit like with an arrow key.
It's probably something as simple as needing to call some sort of update() or something after reset. Hopefully that can get 'ironed out' while phasing out of the beta.
As an opinion: it's decent that you can now reset while in editing mode and it will stay in editing mode, it's not recalled that a user could do this before this update. Thanks.
Here's a quick .gif demonstrating what is mentioned above:
P.S., For what it's worth, a hairpin doesn't manifest this problem when doing the same behavior upon it.
Comments
Fixed in branch master, commit 305365a941
fix #298966: fix grips drawing in some cases
In reply to (No subject) by Jojo-Schmitz
Although this commit probably fixed it, this scenario also occurs when switching up/down positioning of slurs in the first 3.4 Beta
It indeed got fixed after the beta got released
Automatically closed -- issue fixed for 2 weeks with no activity.