copy/paste doesn't work with a list selection (and never did, for notes/rests), only with a range-selection.
click on the A, shift+right, shift-left, Ctrl+C, 4*left, Ctrl-V
Unable to Copy/Paste a single selected note/rest with Nigthly
This still is a list selection, with only one element (just like a note is a chord which just one notehead)
Anyway, you're right this does work in 2.0.1 and 1.3, so we're having a regression here
Previously, this only would have worked if you clicked the *rest* in the second measure before pressing Ctrl+V, right? That is, it woudn't work it you select the measure itself? It's probably kind of an accident it ever worked when selecting the rest as the target, but I think it stopped working before of this change of mine:
It is designed to prevent crashes or other bad behavior that results from attempting to paste elements onto targets that are not actually designed to accept the paste, by checking first whether the target will accept the element being pasted. Rests claim they won't accept a note, but in actuality, they do.
We could back out that change of mine - it wasn't needed to solve the problem I was solving, but it seemed it would solve other potential problems. It also had the potential to create situations like this, where something that happened to work before stopped working.
On the other hand, we could fix Rest::acceptDrop() to acknowledge that a note is in fact OK. Chances are there would be other similar similar things to fix too. Might be safer for 2.0.2 to back out this change, but leave it in place for the master and fix the other places where acceptDrop() is not returning good information as they are found.
Sure enough! Probably just as well. Adding the line you mention is a good fix if we leave my previous change in place.
The main use of acceptDrop() is, as I understand it, to help the drag & drop code know when to highlight a potential drop target. So if you are dragging something from the palette and your mouse reaches an element, acceptDrop() is supposed to say yes or no according to whether or not it makes sense to allow the palette icon to be dropped there. So for the most part, it is reasonable to expect acceptDrop() to return true for anything that drop() is designed to handle. It just so happens we also use drop() for copy and paste of single selections, and that can occasionally involve elements that would never normally be added from the palette, like notes. So those are cases where there might well be code to handle the operation in drop() in order to support paste operations, even though acceptDrop() does not know to allow it because it would never happen for drag & drop.
As far as I understand the situation, it should still be good to fix any such issues we find where acceptDrop() is out of sync with drop() in that way. Which is to say, anything we allow to be be added to a particular from the palette should probably be allowed via paste and vice versa. However, I have no idea what corner case exceptions might exist where some element really should accept drops from drag & drop but not from paste or vice versa.
Comments
I can't reproduce. Have you checked your selection filter?
Yes,
Create a new score.
N 5 A B C D
Select A, Ctrl+C and Ctrl+V in second measure dosen't work.
Doesn't work even if i use Copy/Paste contextual menu.
Robert
copy/paste doesn't work with a list selection (and never did, for notes/rests), only with a range-selection.
click on the A, shift+right, shift-left, Ctrl+C, 4*left, Ctrl-V
Hmm, I'm wrong, this did work in 1.3 and 2.0.1
It's not a list selection but only one note selection. Click on one note.
This still is a list selection, with only one element (just like a note is a chord which just one notehead)
Anyway, you're right this does work in 2.0.1 and 1.3, so we're having a regression here
And work in previous nightly
Oh, OK, which version exactly did work?
83ae627 ?
If so the one-line fix for #65066: Score elements not deselecting after "select all" option broke it
This one is the last who work
79bf72e
2015-06-26
So it is one of these 3 commits that broke it:
dc261b4, 83ae627, 656451f.
dc261b4 is still my favorite, as it is the only one dealing with selections.
Hold on, 656451f too fixes a copy/paste problem, #45356: manual position of a line (8va, cresc., etc.) not preserved on copy/paste
83ae627 fixes something seemingly unrelated, #66776: "V" shortcut does not affect the ties and slurs which extend on the following system
However, I don't see anything obvious in either.
OK, it is not dc261b4 (i.e. the problem still exists after having reverted it)
It isn't 83ae627 either ...
And, now it is getting bizarre: it isn't 83ae627 either!
Are you really sure it worked in 79bf72e ?
Yes, the four Nightlies (79bf72e, 3279e57, e87678e, ea43dd9) on June 26 works:
Not the first on June 27: 656451f
To fix: #45356: manual position of a line (8va, cresc., etc.) not preserved on copy/paste
Very strange, reverting those and rebuilding didn't get it to work for me.
Previously, this only would have worked if you clicked the *rest* in the second measure before pressing Ctrl+V, right? That is, it woudn't work it you select the measure itself? It's probably kind of an accident it ever worked when selecting the rest as the target, but I think it stopped working before of this change of mine:
https://github.com/MarcSabatella/MuseScore/commit/957296f93fa4a76e0d30b…
It is designed to prevent crashes or other bad behavior that results from attempting to paste elements onto targets that are not actually designed to accept the paste, by checking first whether the target will accept the element being pasted. Rests claim they won't accept a note, but in actuality, they do.
We could back out that change of mine - it wasn't needed to solve the problem I was solving, but it seemed it would solve other potential problems. It also had the potential to create situations like this, where something that happened to work before stopped working.
On the other hand, we could fix Rest::acceptDrop() to acknowledge that a note is in fact OK. Chances are there would be other similar similar things to fix too. Might be safer for 2.0.2 to back out this change, but leave it in place for the master and fix the other places where acceptDrop() is not returning good information as they are found.
Ah, seems the list of commits threw me off track, that commit is 4 days old, but got added to 2.0.2 branch only yesterday.
Adding the line
|| (type == Element::Type::NOTE)
in libmscore/rest.cpp, around line 204 seems to fix this problem. Not sure whether this has other ill effects though.
@Marc: your idea of daisy chain to ChordRest::acceptDrop() does not work: that method doesn't exist
Sure enough! Probably just as well. Adding the line you mention is a good fix if we leave my previous change in place.
The main use of acceptDrop() is, as I understand it, to help the drag & drop code know when to highlight a potential drop target. So if you are dragging something from the palette and your mouse reaches an element, acceptDrop() is supposed to say yes or no according to whether or not it makes sense to allow the palette icon to be dropped there. So for the most part, it is reasonable to expect acceptDrop() to return true for anything that drop() is designed to handle. It just so happens we also use drop() for copy and paste of single selections, and that can occasionally involve elements that would never normally be added from the palette, like notes. So those are cases where there might well be code to handle the operation in drop() in order to support paste operations, even though acceptDrop() does not know to allow it because it would never happen for drag & drop.
As far as I understand the situation, it should still be good to fix any such issues we find where acceptDrop() is out of sync with drop() in that way. Which is to say, anything we allow to be be added to a particular from the palette should probably be allowed via paste and vice versa. However, I have no idea what corner case exceptions might exist where some element really should accept drops from drag & drop but not from paste or vice versa.
See https://github.com/musescore/MuseScore/pull/2099
Fixed in branch master, commit 9392451fac
fix #66956: allow a note to get dropped onto rest
Fixed in branch master, commit c212864e2b
Merge pull request #2099 from Jojo-Schmitz/paste
fix #66956: allow a note to get dropped onto rest
Fixed in branch 2.0.2, commit a667b80687
fix #66956: allow a note to get dropped onto rest
Automatically closed -- issue fixed for 2 weeks with no activity.