Beam/line handles not cleared upon Ctrl+click
Reported version
3.4
Priority
P2 - Medium
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.4.2.9788, revision: 148e43f
There may be more than one issue here:
- Open the attached MS3 file and observe measure 5.
- Try to select the "2" fingering (above the beam) with the mouse.
Result: It is difficult, if not impossible, to select the fingering. The beam is preferentially selected. - Try to select the "1" fingering the same way.
Result: Selection is relative easy. - Now use ctrl+ click to select both beam and note, then use the same to deselect the beam
- Now right-click the selected fingering and chose Select > "More…"
Expected result: "Fingering" should be the "Element type".
Actual result: "Beam" is showing as the element type.
Now open the MS2 file and compare how easy it is to select fingering, even when it is right next to other elements.
| Attachment | Size |
|---|---|
| fingering_beam_selection_ms3.mscz | 8.31 KB |
| fingering_beam_selection_ms2.mscz | 9.48 KB |
Comments
The way the beams are laid out, these elements are considered to overlap (the "bounding box" for the beam is a rectangle encompassing the whole beam). Plenty of similar cases exist in MuseScore 2 but didn't happen to in this case. But MuseScore 3 has a simple solution to the problem of selecting overlapping elements - just Ctrl+click to deselect the current element and select the one underneath.
Actual result: The beam is selected instead.
Actual result: The "2" is selected, but the beam stays selected as well, even though no longer highlighted. It's virtually impossible to select the fingering.
Result: The problem disappears.
Conclusions: (1) There seems to be an issue with the Ctrl + click command. Perhaps there is a conflict here with its list selection function? (2) The issue seems to occur with longer note beams (as shown by point 4, above).
It is as I said above: the issue is simply that the bounding boxes for the elements are not perfectly, they are rectangular approximations. So it's not about Ctrl+click specifically, just a generally issue that we can't always detect exactly which element is being clicked on. But as I also described above, Ctrl+click provides the workaround when the bounding boxes overlap.
What makes you think the beam is selected even though it isn't highlighted? It isn't. Try pressing "V", for example. You'll see only the fingering is made invisible, as expected.
Yes. "V" works as expected, but try this:
Expected result: The beam is unselected (losing its blue highlighting), and the fingering is selected (turns blue). The fingering moves up or down with the keyboard arrow presses.
Actual result The beam loses its blue highlight but the handles are still visible. The note turns blue, indicating a selection. Pressing the arrow causes the beam to move up and down instead of the note.
Note: It is practically impossible to select the "2" directly with the mouse—except by zooming the score and clicking exactly on the bottom-left part of the fingering.
Ah, I see, in this particular case there does seem to be a glitch. I think it's not so much with the selection itself - it is correctly selecting the fingering, as evidenced by the status bar and the Inspector. It's that the handles aren't cleared up, so the arrow keys remain active on the handle until you click in the Inspector. Somehow the deselection of the beam is not clearing the handles. I'm not familiar with that handle management code, but I guess when the new handle model was implemented, it missed this case.
You can also reproduce this very simply just by clicking any beam or line (slur, hairpin, etc) then Ctrl+clicking it again - no overlapping elements involved. The status bar and Inspector correctly tell you nothing is selected, but the handles remain active.
Relates to #311174: [EPIC] UI/UX issues and suggestions