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

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):

https://www.dropbox.com/s/74t4pw83i2sfqoj/Dorico%202%20Chord%20drag%20erase%20bug%202.mov?dl=0

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.