Elements are hard to click
Open the attached score, and then try to click the text "Db Gliss". You'll notice it can be hard to click, that doing so will likely select the glissando element behind it. I'm not sure what is causing the issue exactly, but my guess is that it's one of two things, or a combination of both.
First, I noticed that the glissando element has quite a large area in which it can be selected, meaning you can click in spaces around it and the glissando element will be selected.
Second, in reference to the "Db Gliss" text, when and element has a lower stacking order, the element becomes easier to click. However, that causes the glissando, which now has a higher stacking order, to appear over the text. So, the stacking order seems to be functioning a little wonky. I would expect that an element with a higher stacking order would be easier to select, but that's not what is happening.
| Attachment | Size |
|---|---|
| Elements Hard To Click.mscz | 6.96 KB |
Comments
Starting in version 3.1 you will be able to pres ctrl and click the same spot to get different item in the same location.
In reply to Starting in version 3.1 you… by mike320
Interesting. That will help work with the issue, but I don't think it fixes it. I still think higher stacking orders should get priority for getting clicked on.
Also, unrelated, I would think using ctrl to alternate selections like that would interfere with trying to select multiple things. What if you wanted to select both elements that are sitting atop each other. So, wouldn't a different key, like "Alt" or "Ctrl + Alt" be better for alternating selections in the same location?
In reply to Interesting. That will help… by Sean Oliveras
@Marc Sabatella should address that, he's the one who wrote the code.
In reply to Interesting. That will help… by Sean Oliveras
stacking order isn't "depth" / z-index in MuseScore; it's the automatic placement vertical avoidance order.
In reply to stacking order isn't "depth"… by jeetee
Actually, it is depth. The following text can be found in the Handbook: https://musescore.org/en/handbook/3/automatic-placement#stacking-order
"Select the element and change the "Stacking order" value in the Inspector.
In cases where elements are allowed to overlap, Stacking order controls the order in which they are placed on top of each other. The element with the lower value will be placed behind."
In reply to Actually, it is depth. The… by Sean Oliveras
Consider me corrected.
In reply to Interesting. That will help… by Sean Oliveras
It is true stacking order defines the order in which things are drawn, and as of my change touse Ctrl to cycle through elements, it should also have a more predictable effect on which element is selected when you click overlapping elements.
As for trying to choose two elements on top of each other, that's not possible now either, so I guess I wasn't too worried about that. The old workaround of moving one temporarily so you can click them more directly still works. Alt+click has issues with some window managers (eg, on Linux) which is the main reason I didn't use it.
In reply to It is true stacking order… by Marc Sabatella
How about Ctrl+Shift+Click? Could that work for choosing which stacked element?
Also, what about the other thing I brought up? I noticed elements with a higher stacking order are harder to click and ones with a lower order are easier. I think this should be reversed, with higher order being easier to click.
In reply to How about Ctrl+Shift+Click?… by Sean Oliveras
Did you test with 3.1 beta? As I mentioned, I did optimize the calculation of which element would get selected, as there were issues with voice 2 getting preference over voice 1, how stems versus noteheads were processed, and some other specifics. Aside from that I'm not sure there are any logical reasons for preference based on stacking order since the order is mostly dependent on details of the layout algorithm as opposed to anything a user might care about. but in any case, the alogirthm is different so I'd encourage you to check it out and then let me know if you still see specific issues.
As for Ctrl+Shift+click, maybe. Shift is so associated with range selections I'd be hesitant without strong consensus.
In reply to Did you test with 3.1 beta? … by Marc Sabatella
I do understand the point about the ctrl+click preventing the selection of both items. There is the option of using the drag selection for a group of items this prevents from selecting but if you want 3 out of 4 items selected, you probably still have the same issue with the new ctrl+click feature. You still can't easily do that.
In, the big picture the number of limitations has not changed with the ctrl+click feature added by Marc, but rather the existing limitation is different. In other words, previously we couldn't select items that were stacked and we still can't. Being stuck with one item is not ideal, but the item we are stuck with now is our option not the program's. We do now, in most cases, have a better way to choose which items are selected.
I think the current limitation is of little consequence. If you want to select several staked notes, then you still have the shift+click option to select the chord as well as the filter selector to deselect unwanted notes. Otherwise, the items that are likely to be stacked are not similar and you would seldom want to act on several of them in the same way at the same time.
I'm open to common examples of where I'm wrong. I agree with Marc that shift is so tied to extending a selection that I don't see it as a good alternative to the problematic alt key - which would be preferable.
In reply to Did you test with 3.1 beta? … by Marc Sabatella
Another thing. If Ctrl+Shift goes back to what it was before, and Alt+Shift were the new cycle behavior, I guess I still don't see how you'd get both behaviors at once? Or maybe a third shortcut Ctrl+Alt+Shift would be needed to do this? Sorry, my brain is a little fried right now, maybe I'm missing something obvious...