View shifting upon Select Next Element
Anyone else experience this?
The exact steps haven't yet been deduced, but there is a bug somewhere having to do with traversing "next element." It happens when there's more than a handful of instruments and the screen doesn't incorporate all of them at once and while zoomed in. It seems especially to happen upon slurs. Apparently MS is calibrated to "re-set" the view, as if it thinks that what is next is not in view when in fact it is, which screws up the user's view point.
I know this isn't an exact step showing, so it might not help much, but at least for now, here's a demonstration: The MP dynamic is selected, and the slur will be selected from invoking ALT+Right, and when selected, the view is shifted. This shifting ought not to happen since it is already in plain sight. Here I'm merely pressing ALT+RIGHT and then ALT+LEFT back and forth a few times to demonstrate the shift. This is in Page view + Page Width setting for zoom:
I understand it's easy to ask for "a score" to "help better assist" ;] , but still, it happens again when the instruments exceed the screen, and especially with slurs for some reason - although it doesn't seem to be confined only to slurs.
Maybe later will try to get a sample score to upload also, but for now this is merely the complaint and hope someone else has experienced it or knows about the flaw, because it would be nice if it could be fixed up if not for 3.3 at least the next master continuation.
Comments
FWIW, 3.3 is only going to receive fixes for critical regressions at this point, so I wouldn't spend a lot of time worrying about trying to reproduce this really quick. But, of course, exact steps will help if/when it does get to that point.
What I can tell you is that the function that tries to position the canvas gets called on every operation, and it has no "memory" (no concept of what command you just issued, no sense of what was previously selected, etc)- all it knows is what this current selected and what is currently in view. If it thinks the newly selected element is not in view, or is too close to a border, if will try to reposition to allow that element to be better in view. Also, some elements don't exist in a single place, so we do sometimes try to step back and consider the system as a whole, so the fact that you are seeing this only when systems don't fit is consistent with that code kicking in.
It's extremely delicate code, changing on aspect of the calculation often helps one case but hurts another. So while I agree what you show isn't ideal, I wouldn't hold my breath on it.
In reply to FWIW, 3.3 is only going to… by Marc Sabatella
Still on 3.2.3 here, but it is observed that clicking these elements (slurs, hairpins) with the mouse does not shift the view. In that sense, the resulting [selection+view] from keyboard and mouse should be equivalent, but they aren't. Point in mentioning this is that, if it still applies to 3.3 later, if clicking via mouse doesn't have a problem, why not merely activate selection by the same method that occurs when the mouse selects? Maybe this is over simplifying, but it might be as simple as that for a few situations. Then again, maybe mouse-selection should be doing some more view-shifting than it currently is, so there's that also...
Either way, it looks like for future development the mouse and the keyboard should become more closely related in the resultant view-shifting of selecting an element.
In reply to Still on 3.2.3 here, but it… by worldwideweary
It's obviously impossibe to click something offscreen, so checks can be skipped. but again, once we.decide to check, we have no memory of what was selected before. So if something is close to the margin, we adjust. If we didn't , people explain that other operations don't reposition well enough (plenty of issue reports - mostly fixed now - to demonstrate that). It's a constant back and forth trying to hone in on the best compromises, but again, any change made to optimize this case makes some other case worse.
In reply to It's obviously impossibe to… by Marc Sabatella
Yes, but if a slur is partly colliding with the view-port (like only half of a slur is showing) and the mouse clicks the slur, the view does not shift so that it is in full view. Whereas it can be demonstrated to have a full in-view slur and [select next element] with keyboard will actually shift the view needlessly. This doesn't seem like it should stay this way, and there's got to be some logical rules that would result in the least "compromise".
In reply to Yes, but if a slur is partly… by worldwideweary
Like I said, we know it's impossible to click something off screen, so we quite simply do not call the function responsible for checking whether the screen needs reposition. Like, literally, on clicking to select, the function adjustCanvasPosition() never gets called. That's why you can click even 1 pixel from the edge of the screen and it doesn't reposition. But clicking is virtually the only operation that is guaranteed to result in the selection still being on screen. Pretty much every else ends with a call to adjustCanvasPosition() to make sure the selection is in view. And here is where it gets complicated, because depending on what was selected previously, and what operation you just performed, you might want different things to happen - but adjustCanvasPosition() simply does not have access to either of those bits of vital information. It only knows what is in view now, and what element we are trying to make be in view (generally, the primary selected element).
If we didn't scroll the view when the selected element was near the edge of the screen, then, for example, playback would allow readahead, note input would be inefficient because you'd never see the next measure once you reached the edge f the screen, and lots of other things that people have submitted bug reports for and we fixed but would break again because they depend on the very thing you call "shift(ing) the view needlessly". Like I said, it's impossible to change the behavior in one case without affecting other cases, often negatively.
In reply to Like I said, we know it's… by Marc Sabatella
Hopefully in the future some creative programmers can revamp the current way it's designed so that the error of re-positioning doesn't occur while using the keyboard when an element is already in full view, and maybe implement the ability to re-position view when an element has been selected (via mouse) which isn't fully in view.