Display of line handles while editing is different from expected

• Aug 11, 2020 - 18:54
Reported version
P3 - Low
Graphical (UI)
S4 - Minor

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit):, revision: 43c5553

When you select a line, both start and end handles are highlighted. This is a change from previous versions in which only the end handle was highlighted—as shown below.

(Example from MS 2.3.2)


Click on a line, then use Shift + forward arrow. The line is behaving as expected: it's just the display that needs correcting.

BTW: 3.3.4 does not show any handles on select/single-click (and the last on double-click)
It also doesn't add a like on single-click, either is a 3.4 feature/change IIRC

Title Lines: when selected, both start and end handles are highlighted (instead of just the end handle) Display and editing of lines is wrong
Severity S4 - Minor S3 - Major


This is the behaviour of a line in MS 3.4.2:

  1. If you single-click on a line, the line turns blue but NO handles are selected (expected).
  2. If you then use L/R arrows, the middle handle becomes selected on the first click, each click moving the whole line 0.1 sp (expected)
  3. After step 1 if you use Shift + L/R the middle handle becomes highlighted (unexpected) and the end handle moves (expected).
Status active needs info

I'm not so sure this isn't by design, although maybe it was an oversight. The real question is, does this cause any actual problem in real-world usage? If so, can you attach a sample score and describe the specific use case for which this is problematic?

Severity S3 - Major S4 - Minor

IMV, this is how the display should work:

Select line with a single click

  • Current behaviour: When you click on the line it turns blue and both start and end handles are highlighted.
  • Should be: Same as MS 3.4.2. Line turns blue but handles are not highlighted.

Select line then use L/R arrows

  • Current behaviour: The middle handle is highlighted in grey-blue but the start and end handle also remain highlighted (in purple). Whole line moves 0.1sp at a time.
  • Should be: If it intended that this command automatically select the middle handle, then only the middle handle should be highlighted during operation. Colours of handles need to be consistent?

Select then use Shift + L/R arrows

  • Current behaviour: Middle handle turns grey-blue, start and end handles remain highlighted in purple. End handle moves 1 note/rest per application.
  • Should be: If it intended that this command automatically select the end handle, then only the end handle should be highlighted during operation. Colours of handles need to be consistent?

Note: In 2.3.2, the highlighting of handles was always in blue.

Severity S3 - Major S4 - Minor

Again, though I'm asking for a clear description of a real world use case (including sample score) that illustrates of why you prefer the previous behavior. Does the new behavior result in more clicks, more likelihood of unintended consequence of a particular common action, or what? An understanding of how this change actually impacts real world usage is what will allow us to prioritize this, and in fact to even decide if it's a bug or not. So, please leave the settings where they are. We can change them once the additional requested information is provided and we understand the impact.

Although line-editing works as expected, IMV, the highlighting of handles looks inconsistent:

  1. You click on the line and both start and end handles are highlighted. Why not highlight just the end handle, or all handles, or no handles?
  2. You click on the center handle and it turns grey-blue? Why not purple like the end handles? And why do the end handles stay highlighted when you click on the center handle?
Title Display and editing of lines is wrong Display of line handles while editing is different from expected
Status needs info active

I don't know the answer. I don't know that it was intentional, I don't know it isn't. I'm just trying to understand the problem. I think the wording of the original title threw me, I thought you were saying there was a problem in how the lines were actually printing, or in how they actually responded to certain editing actions. So getting clarification helped. I've updated the wording and status accordingly.

Unless the old behavior was a bug that is now fixed, or if it was just an intended improvement somehow. Still not clear. But in any case, given it is just an on-screen visual things that doesn't affect workflow, it's definitely minor, so not the sort of regression we need to worry about for 3.5.1 unless someone who knows this code happens to have time to look.

In MS 3.4.2, single-clicking highlighted the slur/line/glissando in blue but left the handles unhighlighted. Double-clicking always highlighted the rightmost handle. As expected.

But in MS 3.5 there is an issue with single-clicking lines and glissandos: the start/end handles are highlighted in error (but notice that slurs are unaffected).

Once again, we all see that this is a difference; we don’t need further clarification about that. What is still not clear is if this was a deliberate change. It could well be by design as part of the new behavior for dragging, to help clarify that anchors will be affected. We would need the people who designed and implemented this to weigh in.

In reply to by Marc Sabatella

This is not exactly what I had in mind when I redesigned the line behaviour. Basically, here's what I think should happen (fairly standard really)

1: Make the handles bigger - so they are more obvious and 'clickable'. Give them obvious selection states. At the moment, the pink lines are giving the impression that they are the selection states.
2: Make both handles appear to not be selected when you click on a line (but keep the pink lines that show the start and end point)
3: Do not remove the lines when you select a handle. Keep them on all the time. They should not be used to indicate that one or the other handle is 'selected'

I can write this up as a little mini spec if someone wants to jump on it. I've felt for a while that our handles don't look interactive enough and there are more than enough examples in other apps that make me confident that this will work perfectly fine.