Obscured/Unselectable elements
Attached is an excerpt from a (piano) score so busy that it is impossible to select a newly created element.
Details:
The element in question is the last (horizontal) line, between the staves, near the end of the measure, under the triplet bracket. It was created both in this position and unselected.
Reproduce:
I wanted to create a dotted melody line (similar to the previous dotted melody line) between the C natural (staff 2, beat 4, displayed in staff 1) and the following G (staff 2, beat 4+2/3). The C natural is displayed in staff 1 as a performance hint. After control selecting both notes (C natural + G) and double-clicking the line element in the palette, Musescore creates the horizontal line displayed in the attached file. It is created unselected, and therefore impossible to move via keyboard shortcuts.
Question:
Not much of a problem - the shadowing tuplet bracket can be temporarily disabled via the inspector. However, it begs the question: does Musescore need functionality to select obscured elements? Graphics programs such as GIMP or Inkscape provide something along these lines.
| Attachment | Size |
|---|---|
| test.selection.mscz | 13.2 KB |
Comments
If I understand the problem:
Add a line, where you want, from the palette;
Right-click on the new line: select all similar element;
Delete
It would be good to have a way of selecting an obscured element. If you zoom in enough you can usually achieve this but it is time-consuming. Some sort of local zoom feature would be great.
In reply to It would be good to have a by underquark
I zoomed in: that line could not be select (originally created with Linux). Regards.
Yes, we need a way to select obscured elements. It's something I've been thinking about implementing.
My proposal is that we tie this to the existing Ctrl+click functionality. Currently, Ctrl+click selects an element (adding it to the list of selected elements) if it is not selected, or unselects it if it is selected. I would change this so that if the element clicked is selected, we look to see if there is another element *underneath* it, and select that instead. So in the case of ordinary non-overlapping elements, there is no change in current behavior. But in a situation where we have, say, three overlapping elements A, B, and C (with A on top, C on bottom), an initial Ctrl+click would select A (as it does currently), but a *second* one would unselect A (as it does currently) but *also* select B (new behavior). A *third* ctrl+click would unselect B and select "C". A *fourth* ctrl+click would unselect C. At that point, the cycle would continue - the next ctrl+click would re-select A, etc.
Another case when an element is completely covered: a quarter rest from the 1st voice will be overlayed over a quarter rest from the 3rd voice. In a case like this, it might helpful to show visual feedback indicating that an element *is* selected. Inkscape uses an always-visible outline, but if the objects are idental and perfectly overlayed, an outline doesn't help differentiate which object is selected. If we want to use something similar, MuseScore can color the outline corresponding with the corresponding voice color.
@Marc:
How do you select multiple stacked objects, or move the selected objects around without changing the selection? That's why inkscape uses a separate key (alt) to cycle between stacked objects. Inkscape has selection down to a science - see the sections "Multiple selections" and "Selecting under and dragging selected". Unfortunately, MuseScore can't use inkscape's model without breaking backwards compatibility. Inkscape squashes axis locking into a single "smart" key (ctrl) which MuseScore splits across "shift" (vertical) and "ctrl" (horizontal). Musescore also uses "ctrl" for horizontal stretching. Anyway its a really complicated topic, and this is kind of a cop-out, but you should definitely check out Inkscape yourself.
@Shoichi
I don't follow, but I can use the first line to "select all similar elements", which selects the second line, and then unselect the first line. I've also discovered that drag selection (shift+drag) is also able to select the obscured line, and nothing more.
In reply to Another case when an element by orbisvicis
You mean, how would moving elements work if my scheme were implemented? I don't see why it would need to be different than now: Ctrl+click if followed by drag without first releasing the button will initiate a move. Then you need to release the Ctrl key to un-constrain the move. Which of course is far from obvious or ideal, but that's how it works now, and I don't think my proposa.l would in itself change that. I'd certainly werlcome a change to that, though, and maybe Alt could be involved indeed. I have used Inkscape once or twice and will definitely check further before implementing anything. Thanks for the suggestion!
In reply to Another case when an element by orbisvicis
So I started working on this, and couldn't get Alt+click to work on my system. I checked on Inkscape, and it doens't work for me there either. Could be some special keyboard setting on my system (a bit unusual, a Chromebook running Ubuntu under a chroot, so lots of things are a bit odd). WOndering if that's really just me, though, or if Alt+click might be reserved on other systems as well.
But FWIW, I do have a proof-of-concept implementation using Ctrl.