Wild jump occurs when pasting in continuous view.
Cadiz1 asked me to open a new thread on this. I now have 2.2.1 on my computer so I can be sure it has not been fixed.
I'll start with pictures so you know what the problem is:
Start by selecting a measure and copying it
Move the score so that less than about 1/2 of the measure before the one you want to paste into is visible.
Then paste into the measure and see the results
As you can see the score has jumped so only the beginning of the destination measure is visible. My expectation is that the score view will not change in this case. It is very annoying, especially when the previous measure is rather long and the paste area is wider than the screen (not demonstrated but common in classical music). This is most annoying when trying to speed up the transcription process by copying unison sections from one instrument to another.
The zoom level affects how much of the previous measure must be visible. When I made the zoom about 265 I had to have only about the last 1/4 of the previous measure visible at a zoom of 100 the jump happened with slightly more than 1/2 of the previous measure visible. From what I can tell, the number of staves has no affect on the jump, and I don't normally use copy and paste in page view.
Here is the score I tested with.
Comments
Thanks for the detailed report!
I suspect this will turn out to be the same issue as I investigated here:
https://musescore.org/en/node/138701#comment-707771
I believe the issue is when MuseScore detects that the thing it is trying to keep in view is very close to the left edge of the screen, we erroneously think it will make sense to pan to the right - which is exactly the right thing to do if you are navigating backwards through the score (eg with left cursor key) but completely wrong almost any other time.
In order to fix this, I propose we add a new parameter to adjustCanvasPosition() to help understand reason for the adjustment so we can differentiate adjustments that make sense while moving forwards (eg, cursor right, also note input) from those that make sense while moving backwards (eg, cursor left) from those that make sense when not moving at all (eg, paste).
In reply to Thanks for the detailed… by Marc Sabatella
I propose that when paste is used adjustCanvasPosition() should be bypassed. When I, and I would guess most people, paste something into a score I expect the canvas position to remain the same, but what is pasted to be inserted into the score even if it runs off the right hand side of the screen. In my comment about pasting unisons, it is common for several instruments to be in unison rather than only two.
In another place you correctly stated that the current cursor position and last note edited should both be visible if this is possible. This is always possible in continuous view and adjustCanvasPosition() should make this adjustment without relying on ensuring a measure is visible. Or, if as you suspect, it was made to accommodate a back arrow when the newly selected note was not previously visible, it should check that this is the case before making the jump described in my report.
In reply to I propose that when paste is… by mike320
Disabling the adjustment on paste might make sense sometimes, but there are cases where the layout changes sufficiently that it would need needed to keep the pasted area in view (eg, the result of the paste changes the allocation of measures to systems or of systems to pages). Not that we get this right currently, but it does point out the issue is a bit more complex.
The real problem here, though, is that the issue you are describing happens not just on paste, but on practically any other operation that triggers a pan. If you're within 5% of the left edge of the window in continuous view, anything that triggers a pan will force things to the right.
I'm currently experimenting with a crazy simple change that would address this without the need for any additional smarts about the purpose of the pan. What if we decided it just wasn't that important to pan the score all the way to the right even when navigating backwards (cursor left)? What if we just made sure that as you navigate left, the selected element stays on screen? Meaning after your cursor reaches the left edge of the screen, we would actually only pan just enough to bring the note you are navigating to on screen.
That's a one-line change. Probably someone would complain that they wish cursor left was better about showing more context, but maybe it's a good tradeoff.
In reply to Disabling the adjustment on… by Marc Sabatella
Your one-line change makes sense to me. If you are moving the arrow to the left there is no expectation that the newly selected item would end up all the way to the right of the screen. I have seen many programs where placing the cursor on the left of the screen and pressing the left arrow reveals only a single item at a time. This make sense to me. If I want more than a single element visible then I should move the display manually or use other keyboard commands to display more elements.
One related questions. How would this affect the situation where you add a note on the right edge of the screen. What currently happens is that the last entered note jumps off the left side of the screen and you can only see the cursor position.
In reply to Your one-line change makes… by mike320
In general, since so much note entry is done left to right, I do feel that as you reach the right edge of the screen, the vast majority of people would want the canvas to pan to put the working area as far to the left as practical - the idea being that one big jump now means it won't need to happen again for a while.
Anyhow, am currently experimenting with code to try to keep both the most recently entered note and the cursor position both in view. That also appears to be a pretty simple change.
In reply to In general, since so much… by Marc Sabatella
In the case of entering a line of music, the big jump of the cursor from the right to the left end of the screen is not a problem. The only problem currently arises when you are trying to enter a chord or otherwise modify the last note, such as adding an accidental or ornament. Visual feedback is very important.
In reply to In the case of entering a… by mike320
Makes sense. So the really solve that particular part of the problem we would need to make the bigger change where we keep track of the reason for the pan, rather than just looking at the element we are trying to keep in focus. Even so, we could maybe make a bit of an optimization and not do the big jump from right to left unless we are in note input mode and the cursor is ahead of the selection (which basically happens only after entering a note or rest, otherwise cursor = selection).
In reply to Disabling the adjustment on… by Marc Sabatella
"...the paste changes the allocation of measures to systems or of systems to pages"
This makes no difference in continuous view so it should not affect the canvas position.
In reply to "...the paste changes the… by mike320
Good point. So in principle we could disable the pan for paste in continunous view only. Worth fuerther investigation though. As I mentiond, right now the pan doesn't really happen anyhow correctly in the cases I mention. So it's worth figuring out what is supposed to be happening and making sure it really does, as well as making sure than unnecessary pans don't happen as well.