Let Ctrl+click cycle through selection of overlapping elements

• Feb 20, 2019 - 17:08
Reported version
3.0
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
MuseScore

In the spirit of the usability tweak in #284385: Let right-click toggle between adding rests and notes, I also propose modifying the behavior of Ctrl+click slightly. Currently, it adds an element to a list selection if it is not already selected, removes it if it is selected. I want to keep that but add something to the latter case: if the clicked element is currently selected but also overlaps another another element, we would not only deselect the current element but also select the element underneath. Thus making it easy to cycle through a stack of overlapping elements. Once you reach the end of the stack it would continue to get deselected.

I already wrote the code for this some time ago, just need to update it for 3.0

Comments

• Feb 20, 2019 - 17:26

Maybe I'm still not understanding, but it still works exactly as expected for me when used correctly. That is, if you actually Ctrl+click an element. The only question is what happens when you make a mistake and erroneously Ctrl+click an empty space, correct? I agree it's more useful to protect the user from that by preserving the selection, and am happy to change that while I'm at it. But I do want to be sure there isn't something missing - some actual reason you would want to Ctrl+click an empty space and some specific behavior other than "don't lose the selection" you want to see instead.

Reply

• Feb 20, 2019 - 18:36

"It protected the user from missing an item and having the currently selected items deselected due to an accident"
+1 of course. It is precisely in this spirit, and with this intended purpose, that this improvement was made (I still remember this day... - Lasconic did this fix - , and I and Jojo were so happy!) -;)
As said, intended to avoid any frustration of having to redo/re-select, in the event of typing errors, which can often happen!

Reply

• Feb 21, 2019 - 23:18

A few other glitches I will address that have to do with what gets selected when you click (with or without Ctrl):

  • with overlapping notes, topmost (visible) one should win
  • notes should win over stems
  • when all else is equal, voice 1 should win

Anything else?

Reply

• Feb 21, 2019 - 23:53
Status active ⇒ PR created

In general, that should happen, we use stacking order for most cases of dissimilar types, and it generally gives this behavior already. Notes vs. stems is the one case that comes up over and over where this doesn't hold, making it harder than necessary to select the note itself rather than the stem, particular at small sizes.

Anyhow, here is the PR, I can still add other specific tweaks as needed:

https://github.com/musescore/MuseScore/pull/4717

Reply

• Feb 25, 2019 - 07:04

Cycling through two overlapping notes, when the voice 1 note is selected, it changes the color to blue. But if the voice 2 note is selected, the displayed color is black (because the visible note of voice 1 is now deselected). It would be more comfortable to get the selected note in the foreground, so that its selection color get displaye. For example, when the note of voice 2 is selected, the note should be green.

If there are no additional notes are selected when cycling through the overlapping notes, at least you get visual feedback when the voice 2 button gets green. But if additional notes are selected, there is no visible feedback of cycling to overlapping notes of voice 2. The note color toggles blue and black. The voice 2 button remains gray.

Reply

• Feb 25, 2019 - 15:17

In principle, changing elementLower() in elements.cpp to compare not just stacking order but also selected status could do the trick. I can try looking into this, but it's also easy enough to revisit later.

Reply

• Feb 25, 2019 - 15:23

I don't know that making the user rely on the status bar to figure out what they have selected is such a good idea. That's the only feedback on what you have selected if it doesn't move to the top and change colors. I realize the same thing happened in version 2 when clicking chose something not on top, but it's still not good.

Reply

• Feb 26, 2019 - 03:16

Agreed. I've verified it's easy to fix the drawing of elements in elementLessThan() even without the change to selection behavior, so that a selected element gets shown on top of an unselected element of the same tye. Also, to make visible elements always show on top of invisible elements of the same type, another pet peeve I've lived with too long. Updating the PR accordingly.

Reply