BUG: Chord data loss when dragging chord symbols

Just jumped into Dorico 2, and so far been excellent. But…

When dragging a chord symbol with the mouse, the dragged symbol seems to instantly overwrite any other chord symbol that it touches. The result is that dragging a chord symbol works as a pretty effective chord eraser. The worst part is, Cmd+Z Undo replaces the dragged symbol to its original spot, but doesn’t replace the erased chords! Happens in both Galley and Page view.

I’ve just burned myself a couple times with this before I realized what was happening. Screencast here: https://www.dropbox.com/s/1lva9hpow0es5vz/Dorico%202%20Chord%20Erase%20Bug.mov?dl=0

1 Like

Just curious what behavior you would have expected.

Was that in WRITE mode? If you are in ENGRAVE mode, I could see this would be a problem. But in WRITE mode, this seems like a sensible behavior to me.

Surely ‘undo’ should definitely undo?

After a bit of experimenting, it seems that ‘undo’ does undo some of the deletions, but not others. I can’t (yet) discern a pattern, but I guess this must be a bug.

This behaviour isn’t specific to chord symbols: there can be only one chord symbol at a specific rhythmic position, so if you drag a chord symbol from one place to another, it will overwrite any chord symbol at any position to which the one being dragged snaps to. In order to make this operation feel fast, we don’t update everything until after you release the mouse button. Unfortunately for technical reasons it’s difficult to restore all of the chord symbols when you undo. If you need to move a chord symbol from one place to another and the move will involve crossing the path of other chord symbols, I’d recommend using cut and paste instead.

To be clear here: I would expect the dragged chord to overwrite another chord when the mouse button is released. What I absolutely DO NOT expect is for the dragged chord to overwrite other symbols while the mouse button is still held down. My expected behavior is based on the behavior of most other dragged elements in most operating systems: you can move something from A to B without regard for what’s in between. If the current behavior is expected, it makes dragging very risky, to the point where I would train myself to never drag anything more than a bar or two. Beyond that, it’s far too easy to accidentally erase something.

Another scenario where this behavior is confusing and data-destructive: if you marquee-select multiple chord symbols and attempt to drag them together, what happens instead is that you only drag the specific one you clicked on, and if you, say, wanted to move them to the right and had clicked on the left-most symbol, you end up immediately and irreversibly erasing the very symbols you wanted to preserve. I’ll post a video later of this specific scenario.

But, let me reiterate that this behavior feels very very wrong to me, and very destructive. Users should never have to worry about erasing data when dragging elements around, and I can think of no other systems where a dragging action risks immediate and irreversible data loss.

Here’s a video to demonstrate the 2nd scenario I describe above, where attempting to drag multiple chord symbols at once results in irreversible deletions (and the result when I try to CMD-Z each move):


It seems that there are a few behaviors that, independently, are fairly reasonable (dragging an object in write mode is actually moving the object in real time, an object moved on top of another object overwrites that object, dragging multiple items at once is apparently not supported), but combined, these result in a pretty hazardous situation.

To summarize (in order of decreasing importance):

  1. I can see no justification that dragging anything should ever result in content being deleted in a manner that can’t be undone. That’s a bad user experience, plain and simple.

  2. I think most users would expect that dragging and dropping could be done w/o items in the path being affected. Can you imagine if Finder worked this way? What other system requires you to be careful about where you drag when moving elements around?

  3. I would expect that dragging while multiple items are highlighted would move all those items at once. Though, I could see why this might be technically somewhat complex.

I hate to say it, but Competitor F handles dragging and dropping quite nicely: You get a nice highlighted rectangle around wherever you drag, showing you exactly where you’re about to drop and how much space the resulting paste would take up, and you can move that rectangle anywhere you want without worrying about deleting anything in its path. And of course, you can always undo anything you move. I’m not suggesting that Dorico needs to do that exactly, but I think the 3 points above are reasonable expectations.

As always, I report bugs and write long posts like this because I care, and because the Dorico team has shown such care in crafting a beautiful piece of software and being responsive to user asks :slight_smile: Keep up the great work!

I don’t think your expectations are unreasonable, but as I explained in my initial reply to the thread, the current behaviour is a trade-off. It doesn’t offend me at all to hear that you find FInale’s handling of dragging and dropping items better than Dorico’s: the two programs have utterly different architectures, design philosophies, and approaches. Of course it is useful feedback for us to know that this tripped you up, and I hope it won’t trip you up again now that you know how it works in Dorico, and I would never rule out us making some changes in this regard in future, but for the time being this is the way things are.

Just ran into this issue and almost didn’t realise that when I clicked undo my chord symbols didn’t come back. I’d say that’s very risky behaviour as it might go unnoticed, as one would expect undo to, well, undo everything.

I would love an option for drag operations to only update after the mouse button is released, as I realised when writing this that I tend to avoid dragging things in Dorico specifically because it feels sluggish due to constantly updating the score during the operation.

EDIT: Here’s an operation that is impossible to do in Page View due to the real-time updates.

1 Like

I’m not sure you can fault dorico for this one though; you have consolidated rests turned on and it’s trying to figure out your intentions. If You deactivate them until you’re ready to begin engraving, there would be no problem.

Here’s an example with consolidate rests turned off (although they wouldn’t show here anyway because I removed the final bar from the previous example)

1 Like

That’s a tricky situation for Dorico to deal with because of the changes in spacing, as I’m sure you realise. When Dorico snaps between the final system being justified to the width of the frame and not being justified, because of the additional space needed for the dotted slashes, then of course the rhythmic length of the slash region changes because the mouse pointer stays in the same place, and thus it now much earlier in the region than it was a moment ago, which means fewer slashes are needed, which means less space is needed, which means the system falls underneath the justification threshold again, which means the mouse pointer is now nearer the end of the region again, which means more slashes are needed, which means more space is needed, which means the system exceeds the justification threshold again, which means the mouse pointer is now much earlier in the region than it was a moment ago, which means fewer slashes are needed, which means less space is needed, which means the system falls underneath the justification threshold again, which means…

You get the point.

I have three suggestions: either use the keyboard shortcut Shift+Alt+right arrow to extend the region; or extend the region with the mouse in galley view; or turn off the relevant justification option on the Note Spacing page of Layout Options.

Dear Daniel, I think it’s fairly obvious why it happens. The question is: Is it feasible in future to make Dorico work any differently when dragging certain items? Of course this issue applies to other items that affect the formatting when they are resized. I’m sure you’ve seen Finale in action, when you drag-and-drop a selection with the Mass Mover tool: the destination bar highlights with a heavy outline, but nothing changes until the mouse is released. I think this drag interface model would also be compatible with iOS.

If it’s a No, it’s a No, and we’d better stick with the keyboard. Thanks for your consideration, and may we all have a better 2022!

All things are feasible given sufficient time and attention, but whether this is something that is likely to be worthy of a lot of attention in the short to medium term, given the many other demands on our time and the several different approaches that are possible to avoid the problem… I doubt it.

I agree, it was a very specific example and not really the point I was trying to make; the constant updates while dragging issue is nitpicking and certainly easy enough to workaround, and I can definitely see the benefits in the current behaviour.

For me, the most important part of all this is the chord symbols being irreversibly erased.

That is generally how Dorico behaves when editing items in Write mode with the mouse, and it would be quite difficult to change, I’m afraid. That’s not to say it would be impossible, but it’s not something we are likely to be working on in the near future.

1 Like

It’s something we try to make clear in the documentation, to be as helpful as possible at least!