Last placed element should take precedence
See this discussion https://musescore.org/en/comment/reply/180371/671616
I believe the last placed element should take precedence when clicked. There have been numerous times where over the years when the element added previously (e.g. bar numbers) (underneath to my mind) is selected, and at higher resolutions, it becomes impossible to select the last placed element I am dealing with without unnecessary resolution changes and negating of clicks.
Comments
Thanks for bringing this up! I'm not quite sure, but I think you mean you have two elements that are overlapping, and you are trying to access the one that is *under* the other.
I agree this is a problem, but I'm not sure keeping track of which was added more recently is the best solution. This might seem to make sense for an element you *just* added (and in that case, it should already be selected), but what about elements that were added, say, hours ago? Or, for that matter, *years* ago, if you are just now re-opening an older score? Also, what about the times when it happens to be the older element you want to move? Or when there are more than two overlapping elements?
I think there needs to be a better way of selecting which elements gets selected when clicking overlapping elements, to handle all of these cases. I actually did a trial implementation of a modified Ctrl+click command that would cycle through the various elements in the stack if you have overlapping elements under the mouse. So, first click gets the top element just as it does now, then Ctrl+click deselects it (just as it does now) but also selects what is under it. Ctrl+click again selects what is under *that*, and so on, allowing you to access each element in turn.
It works pretty well, but so far hasn't been merged, and there doesn't seem to be widespread agreement this is a good approach. Maybe there are others, and maybe somehow keeping track of time added could be part of a solution. Worth further discussion for sure!
In reply to Thanks for bringing this up! by Marc Sabatella
I like your idea, but I think you should use Alt-click rather than ctrl. Currently CTRL-click adds to the current selection rather than toggling to another item. What happens when I'm selecting 3 notes that are not overlapping using ctrl-click? I do this, especially when rebeaming measures.
In reply to I like your idea, but I think by mike320
Actually, Ctrl+clcik does both - that's why I chose it. Ctrl+click once and it adds to the current selection; Ctrl+click again and it removes it from the selection again. My implementation does exactly that as well, so there is no change to the behavior whatsoever in the usual case. Only in the case of overlappiung elements is there a change. The first Ctrl+click adds the top item to the selection just as it currently does. The second removes it from the just as it currently does, but *also* adds the next item down to the selection.
While it is possible to change my implementation to use Alt+click, I'd rather avoid that as this might be used in some OS / window managers to do something else. It's also less discoverable. But as I said, worth further discussion. Like, one downside of my implementation is that you cannot use Ctrl+click to add *both* overlapping elements to a selection. You can't do that currently either of course, because there is no way to get the bottom element (short of moving one aside, which continues to work). If Alt+click were to cycle through elements in a stack, it would suffer the same problem, unless we made it so Ctrl+Alt+click added the next item down to the selection *without* deselecting the top element - but then, the same shortcut could conceivably be made to do that even if Ctrl+click were the main cycle command.
In reply to Actually, Ctrl+clcik does by Marc Sabatella
I really appreciate the thought and work you have done on this Marc.
I still think the last added should be on top.
As to how far back one would go, I think that there is nothing wrong with making it session bound, although it could go back, in order. Last/first (period).
I do like your idea of cycling through and I look forward eagerly to this being developed.
Best to all,
In reply to I really appreciate the by xavierjazz
It occurs to me the question of which is on top is kind of separate from the question of how to select the one *not* on top.
Right now, which item is on top is determined by the "Z order" property on the element. Each type of element gets a specific Z order number, so rehearsal marks are above chord symbols, that means all rehearsal marks are above all chord symbols regardless of what order they were added in. It would actually be fairly simple for MuseScore to check when adding an element if that would placer it underneath an existing element, and if so, to bump up the Z order number for that specific element, while still leaving the defaults for each element type the same. So the most recently added would indeed be on top. No need for MuseScore actually remember a history of what got added when - it's just a matter of getting the Z order right at the moment the element is created. So that's worth thinking about too.
Still, though, we'd need a way to select the one *not* on top, and that's where something like what I implemented would come in.
In reply to It occurs to me the question by Marc Sabatella
So great .....
Magnifying glass?
Very rarely do objects completely overlap - if they did overlap perfectly then they would be identical and in the exact same space and I can't see a common need for that. So, there is usually some part of an object that is uniquely-placed in space. In that case, if there was a local "magnifying glass" that could zoom in on a square region of your screen to 800% or so then you could more easily select the object that you want. This would negate the need to zoom in and out of the whole score and would also mean that there was no need to take into account Z placing etc.
In reply to Magnifying glass? Very rarely by underquark
That's interesting, well done.
The only caveat I have as a user is that it requires embarking on yet another series of gestures.
In reply to Magnifying glass? Very rarely by underquark
Well, there is more to it than that. We determine which element you have clicked based on the "bounding box" (a rectangle encompassing the element). So if the element on top is larger than the element below, you might still be able to see the bottom element through the "background" of the top element, but not be able to click the bottom no matter how much you magnify.
For instance, in My First Score, created a chord symbol "C" and a rehearsal mark "A". Position the rehearsal mark directly over the chord symbol, so the chord symbol is completed enclosed by the the box for the rehearsal mark. You will have no difficulty seeing the chord symbol underneath that rehearsal mark, but you will be unable to click it no matter how much you magnify, because the rehearsal mark continues to "win" even when clicking empty areas within it.
Not that a local magnifying glass couldn't be useful, but it isn't a complete solution here.
It would be a fair old rewrite, but a more instinctive selection model would use the 'which element coloured in the screen pixel I just clicked on' rather than a bounding box model. Essentially you redraw the score from front to back into a 1 pixel square image and stop when the colour changes.
In reply to It would be a fair old by phildriscoll
At the moment the bounding box is not visible on screen. Perhaps making it visible is useful although I abhor clutter. :)
In reply to At the moment the bounding by xavierjazz
These do show if you run MuseScore in "debug mode" ("-d" command line option). In current builds for 3.0, you can also turn on display of these boxes from a new Debug menu, but i suspect that might only be available in debug builds.
The natural way would be something like what Windows does these days. Suppose you have 3 Notepad windows open, then there is a single (almost) icon for the application in the task bar across the bottom. When the mouse cursor hovers over the icon, 3 small windows pop up in a horizontal line above the icon. One for each incarnation. Then you click on the one you want.
The same works for file Explorer windows, Internet Explorer (multiple tabs open) and others. I suspect that it's a built in thing available to apps on Windows. That way, it just happens for the user. No need to know about Ctrl-Click or anything. Don't know about Mac and Linux.