Double clicking on a pallet item should not add two identical elements

• Dec 4, 2020 - 11:02
Reported version
3.5
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
Yes
Workaround
No
Project

Since single clicking to add a pallet item was implemented there has been a steady stream of users reporting various problems caused by multiple identical overlapping and hence un-seeable items (notably voltas) being found in their scores to their surprise ("I didn't add them!"). It seems fairly certain that this is a result of the user using the old double click method to add an item.

My suggestion is that when adding pallet items, both single and double click should be interpreted as single click.

Alternatively, a check for the presence in the score pre-existing identical (i.e. identical type, and location) element should be made on any click and if such an element is found, the user should be warned that they are about to duplicate it. However, this is probably a less helpful and more difficult to implement option.


Comments

+1

In windows it is common to need to double click on items rather than single click like on a Mac. Windows users are used to this so the option to double for windows users should remain.

"Steady stream" would suggest a higher frequency than "few"?

At any rate, this seems like an important thing to change.

Frequency Few Many

We seem to have reached the 5=many threshold in this thread.

The "steady stream of users" probably haven't complained about the "double click problem" as they are unaware that their problems arise from double clicking. The results are not apparent visually unless they try to drag the doubly entered item. Their posts arise mainly from the effects of the doubly entered voltas on playback.

FWIW, this seems to only happen for lines as far as I can tell, Suggesting that at some level, we are already handling this correctly, but the line handling is missing whatever is going on for the other elements. Unfortunately I don't understand enough QML to be able to deal with this.

Included in lines are voltas. jeetee is fixing the problem this issue has caused with them because they are not as obvious as some other items that get double added.

Unfortunately I don't understand enough QML to be able to deal with this.
Me neither. To me this is the biggest and most important disadvantage of QML code inside MuseScore

Agreed. I realized a couple of weeks ago this is the root cause of the volta problem but I was trying to figure out how best to discuss it. This issue gave me the opportunity. The bugs jeetee is fixing are real so I don't have any guilt for not mentioning it previously.

Indeed, it's absolutely worth fixing the crashes that occur if double voltas are added, since no doubt double-clicking isn't the only way to create that issue. Consider also, for example, adding a volta to the top staff, then attempting to add voltas to each subsequent staff. They are system elements so they actually keep stacking on top.

As for QML, I can only hope that the "powers that be" are correct in their faith that while the various code structure changes being implemented may make things harder for us old-timers, they may somehow improve the situation for newcomers. It's a reasonable goal, even if it doesn't benefit me as personally as a developer.

In reply to by SteveBlower

I had a fresh thought about this. When a user adds most things to a score, the thing that is added becomes the selection. So for example after selecting a note and clicking on a dynamic in the pallet, the newly added dynamic is selected. Trying to add another dynamic by immediately clicking on the pallet (or making the second click of a double click) can't add another dynamic as no note is selected. However, after adding a line (including slurs), the selection remains what it was before clicking and therefore on the second click of a double click another line can be added.

It seems that transferring focus to a newly added line rather than leaving it with the previously selected range/note would offer a simple fix for the "double click" problem. It would also make the behaviour of lines consistent with other elements. The downside would be that if you want to add a crescendo, say and a slur over the same range, you would have to reselect the range between adding them, but that seems to me to be a small price to pay for eliminating the problem of hidden multiple elements being added that end up causing grief in seemingly unrelated areas - like playback of voltas.

In theory that's a good idea, in reality things are actually tuned a bit as to what is selected after adding an element, for efficiency ion the most common use cases as reported by users. So if the most likely thing you are going to want to do after adding one thing to one note is then navigate to another note, we want focus on the note. If it's to do something - move or change properties - on the thing you added, then we want focus there.

Not saying we do the mathematically optimum things in all cases, but the point is, this is an important goal we shouldn't sacrifice. I'd rather figure out a different solution., like do something different with the layout when two such lines get added to make the error more obvious. Then we also achieve the goal of educating the user that two clicks weren't needed.

In reply to by Marc Sabatella

Your comment about focus being set with reference to what is the most likely next operation makes sense. However, it got me experimenting again. Adding a dynamic while in note entry mode retains focus on the note, whereas when not in note entry mode adding a dynamic moves focus to the dynamic. Thus double clicking to add a dynamic when not in entry mode is OK but results in a duplicated dynamic when in note entry mode. That is surely confusing behaviour. As my standard workflow is to enter dynamics on a second or later pass after I have entered notes I luckily never managed to enter duplicate dynamics that way until I started experimenting.

Doing something different with the layout may be a good way to go. The fact that they currently lie on top of each other makes duplicate elements difficult to detect. Why should duplicate lines, dynamics etc, not be subject to avoidance rules?

Like I said, I am not claiming we are optimal about this, basically we've tweaked the cases where someone successfully argued one behavior was more logical for some particular case. Anyhow, it's just something to keep in mind as we decide how to deal with this.

Not sure exactly why autoplace doesn't resolve these collisions already. I might have blamed the code trying to align things vertically, but that code only exists for a few elements types, and this overlap happens with most, including ones that are not normally aligned.

In fact, the collision resolution really doesn't kick in as I'd expect even when the overlap is not perfect:

Screenshot 2021-01-22 at 9.35.12 AM.png

I guess maybe the first is not added to the skyline yet when the second is processed, something like that.