CTRL+SHIFT+drag behaviour
I noticed that CTRL+SHIFT+drag hadn't been implemented yet in MU4, was going to look at what would be involved in adding it but then started playing with MU3 and noticed:
a) for some lines (hairpin, pedal marks, trills, etc.), CTRL+SHIFT+drag allows creating a copy of the element, but the length is not remembered, instead it seems to always be created such that it ends at the end of the dropped measure.
b) for clefs, time & key signatures, it attempts to duplicate it at the start of the dropped measure, regardless of where you drop it
c) accidentals & dynamics seem to mostly work as expected
d) for other elements (including slurs), CTRL+SHIFT drag doesn't work at all
Also it only cares about whether CTRL+SHIFT are held down at the point the mouse-down event occurs - you can then release them and the drag/copy behaviour is still active. OTOH, if you first press & hold the left mouse button (but don't move the mouse), then press CTRL+SHIFT, then move the mouse, the behaviour seem to be the same as CTRL+drag, which seems to allow just adjusting horizontal position (without re-anchoring).
Normally I expect the dragging mode could be changed at any time by changing what keys are held down.
Can someone explain the use case behind the current behaviour? I can't really see any reason that CTRL+SHIFT+drag would just always create the best possible copy of whatever element you select at what ever exact stop you drop it. Obviously there are some logically impossible operations (dropping time signatures mid-measure!), but certainly there's no reason I can see the length of lines shouldn't be preserved, or that clef/key-signatures can't be dropped anywhere in measure, or that you shouldn't be able to duplicate slurs, text elements, articulations and even chords/rests etc.
Comments
It seems to me that dragging anything is more trouble than it's worth.
a) Why would you CTRL+SHIFT+drag a two measure hairpin when you could just as easily create it the normal way? Or even copy and paste it? Dragging can always be less accurate.
b) Easier to just create the element where you want it.
c) I can't get dynamics to work your way. But again, just create the element where you want.
d) True. It was never intended to.
What would be the possible advantage of using an inaccurate drag system over a precise system?
I confess I didn't know about CTRL+SHIFT+drag before your post. But I can't see much use for it.
In reply to It seems to me that dragging… by bobjp
a) I'd say finding one nearby on the score is often faster than trying to find it in the palette, esp. if you've customized it.
b) likewise, though I personally can't imagine using CTRL+SHIFT+drag for clefs or time/key signatures
c) works fine for me but you have to move the mouse to highlight a note or rest to attach it to
d) that's what I was trying to determine, but the weird thing after a bit more testing it seems CTRL+SHIFT+drag does work for text/slurs/articulations, just not always, still trying to figure out exactly in what cases it's not supported.
As it happens I agree that CTRL+SHIFT+drag is a clumsy way to create copies of objects - using the clipboard would generally be far better, unfortunately that's very limited in MU3. I've actually done quite a bit of work to significantly improve this for MU4 but it's still work in progress and needs quite a bit more testing etc. (but essentially, you can now copy any sort of line, including slurs etc., to the clipboard and paste it where ever you like, and it will do the best possible job of cloning it to the new location with the same properties as the original one).
In reply to a) I'd say finding one… by Dylan Nicholson1
So CTRL+SHIFT+drag for text (incl. dynamics), slurs, articulations & accidentals does work fine - it's just that the tip of the mouse pointer has to be exactly over a notehead (or if it's text, a rest) to work, the rest of the time you see a 🚫 no drop cursor - but that cursor actually makes it quite hard to work out where the mouse pointer would be pointing if it was a note. Note that for slurs, the length and the control points are lost when cloning - it just creates a new slur from the target note to the following one (line type etc. is preserved). I swear I did have one or two occasions where the notehead was selected correctly indicating I could create a copy but then on releasing nothing happened, but couldn't reproduce.
The most important use case use is to add an existing score item to a palette.
https://musescore.org/en/handbook/3/palettes#add-element-to-palette
In reply to The most important use case… by Ziya Mete Demircan
Indeed, and thanks for reminding me to include that in my testing if I do start implementing it.
Logically then CTRL+SHIFT+drag to another element/score location should always do at least what CTRL+SHIFT+drag to the palette, then applying the new palette item to said element/score location does, but even this isn't true currently in MU3 for some cases.
Lines require a start and end segment, so it's not always possible to simply copy a line if there is nothing there at one or both of those tick in the destination to have create a segment. Of course, the copy code could create one, but then we'd have a new case to consider throughout the code - cases where the end segment has no actual notes. Line handling generally depends on a note/chord/rest at both the start and end ticks, so that might be very difficult to get right. On the other hand, it's absolutely something we'd all love to see, because then you could have, for example, a two-beat crescendo followed by a two-beat diminuendo on a whole note. I now that's something @tantacrul has given considerable thought to regarding design, so it would be important to make sure anything done here played into that bigger whole.
Meanwhile, simply rounding off to the nearest tick with a segment (and there are plenty of utility functions for this) would suffice for an initial implementation, I think.
In reply to Lines require a start and… by Marc Sabatella
Preserving the length works fine now when you copy a hairpin to the clipboard and paste it elsewhere, and I've already put up a PR that extends that behavior to all spanners. The only tricky case was note anchored lines, otherwise it just works as expected, no special case logic required.
So doing the same for Ctrl+Shift+drag should be trivial.