Hi. I don't think that the navigator is going to be removed, so don't worry. Actually something like this is not an issue and should be posted in the forums. Issues are for bug and tech problems generally.
I believe scroll bars in the ScoreView would be a valuable addition to the navigator and scrolling with the mouse, regardless of the visibility of the Navigator.
Reasons:
1. For those without a scroll wheel.
2. To make it clear that it is possible to scroll the page and the continuous view.
3. I know very few who actually knows that Shift+Mouse wheel scrolls horizontally, so a horizontal scroll bar would make navigation easier for those.
Enabling the scroll bars could be a preference, such that they can be turned on/off by default/when needed.
Adding scroll bars to the main score will make it much faster to navigate to the top and bottom of a long score. Right now I sing "Scroll, Scroll, Scroll your mouse slowly up the screen..." every time I move from the strings to the flutes, which is a lot - like every page I input from a PDF.
While I have nothing agauinst the option of adding scroll bars (and thus taking screen real estate away from your score), I just wanted to check - have you looked into tweaking your mouse scroll wheel settings in your OS? I never have to do more than a swipe or two to move from top to bottom of a score.
I would be fine with a short cut that said go to top of score in same spot. But that was shot down because I can press some shortcut button 35 times to get there.
Hmm I don't remember that discussion. Your suggestion seems reasonable, the proposed workaround less so :-). Is it possible either someone misunderstood what you were asking or youbkisybderstoodntheir response? Can you link to that thread?
But still, I would be interested to know what's going in with your mouse settings that makes scrolling to the top anything but simple like it normally should be.
I'd still love to see screenshots, though. I guess maybe if you are zoomed way in it might take more than a couple of swipes? It's important to understand the conditions that lead to problems so we can gauge how likely others are to experience the same issue, and also to understand what the best possible solutions might be.
OK, so you are at a size where you can see 5 staves out of 61, and you want to scroll to the top?
I just tried a quick test, and had no trouble doing so in one or two swipes with my current mouse settings. How far does each swipe go for you? For me, a short swipe goes a single screenful, so indeed it would be a chore, but a "flick" (?) of the wrist sends the view all the way to the top or bottom just as it should and does for other programs. Does your driver not provide such an option?
I am also open to the idea of scroll bars. But I am also truly trying to help here. Right now you are saying you are having difficulty scrolling to the top of a page. I am trying to explain to you how you can do so easily *right now*, no need to wait for developers to implement a new feature. I am honestly confused as to you you seem to be annoyed by this help I am offering.
I agree, the current shortcuts do not provide a way to quickly move to the top the current page of your score (or equivalent in continuous view). That is, keeping same measure in view, see top staff. Only keyboard-based method that makes works at all for this is Alt+Up to move one staff at a time, and it isn't particularly convenient for this purpose either, because the view stops following the cursor and in avny event would require you to press and hold for a long time. So a new command to immediately move the cursor to the top staff, keeping current measure and repositioning view accordingly, does indeed make sense to me.
I'm sorry, though, but I'm still confused by the statements about the existing mouse hebavior. One one hand it is claimed:
"Right now I sing "Scroll, Scroll, Scroll your mouse slowly up the screen..." every time I move from the strings to the flutes, which is a lot"
But on the other hand, it is also claimed:
"my mouse works fine"
It seems to me that perhaps you don't realize these statements are at odds. With a properly configured mouse, it really does take only one single swipe to reach the top staff, as I observed above. So either 1) your mouse *can* still stand to have its settings tweaked so that it works as well as it should, or 2) your mouse can already do this and you just need to learn the correct gesture for it. Or, much less likely, 3) your mouse is an older model that doesn't support this feature.
Right now I still don't know which of these is the case, and I'm not sure you do either. So I do hope you will help us get to the bottom of this. If it's 1) or 2), we will have performed a great service for you - solving your problem *today*, no need to wait for some future version. If it's 3), then we developers will know that some percentage of users are on systems that don't support the modern navigation models. We can then prioritize possible new features accordingly, as we gain a better understanding of how many users are affected by this hardware issue. So this also benefits you down the road.
Bottom line, I really am trying to help here, but it benefits us all to understand the situation as fully as possible.
Is it really that hard? My gut sense is that something like this wouldn't need developer time and energy so much as a developer to just change a bool somewhere.
I want to chime in here and mention that this is a huge feature for me. I have old hardware running Linux. A laptop with a mouse pad that cannot support side scrolling. And the vertical scrolling of this mousepad is clunky at best. I like a really zoomed in view on one staff while inputing notes. So scrolling horizontally and vertically is very common.
Scroll bars are the EASY way out, relatively simple, and offer accessibility to everyone.
The navigator is no help in page view since horizontal movement is a chore unless the navigator is so big you can actually see the page. The navigator in continuous view is better. Ideally there would ALSO be a "hand" tool, where on key down, the cursor turns to a "hand" and I can drag the score.
I'm tempted to download source simply so I can implement this because it's almost ridiculous this wasn't a feature when it first came out. Even if it is hidden behind an option... Having been a software and user experience engineer for a decade it's almost laughable. Sorry to be that crass. Regardless I am very thankful for this free tool <3 Thank for reading
Often if your system seems not to support side scrolling, it does if you hold down the Shift key. But if you're equipped to implement this, feel free, and please make a pull request—I think it's very likely it would be accepted.
Comments
Hi. I don't think that the navigator is going to be removed, so don't worry. Actually something like this is not an issue and should be posted in the forums. Issues are for bug and tech problems generally.
Regards,
'Disabled', not 'removed'.
:)
I believe scroll bars in the ScoreView would be a valuable addition to the navigator and scrolling with the mouse, regardless of the visibility of the Navigator.
Reasons:
1. For those without a scroll wheel.
2. To make it clear that it is possible to scroll the page and the continuous view.
3. I know very few who actually knows that Shift+Mouse wheel scrolls horizontally, so a horizontal scroll bar would make navigation easier for those.
Enabling the scroll bars could be a preference, such that they can be turned on/off by default/when needed.
Adding scroll bars to the main score will make it much faster to navigate to the top and bottom of a long score. Right now I sing "Scroll, Scroll, Scroll your mouse slowly up the screen..." every time I move from the strings to the flutes, which is a lot - like every page I input from a PDF.
The navigator shouldn't be a factor in this.
While I have nothing agauinst the option of adding scroll bars (and thus taking screen real estate away from your score), I just wanted to check - have you looked into tweaking your mouse scroll wheel settings in your OS? I never have to do more than a swipe or two to move from top to bottom of a score.
I would be fine with a short cut that said go to top of score in same spot. But that was shot down because I can press some shortcut button 35 times to get there.
Hmm I don't remember that discussion. Your suggestion seems reasonable, the proposed workaround less so :-). Is it possible either someone misunderstood what you were asking or youbkisybderstoodntheir response? Can you link to that thread?
But still, I would be interested to know what's going in with your mouse settings that makes scrolling to the top anything but simple like it normally should be.
My current score has 61 instruments. My mouse is fine.
I'd still love to see screenshots, though. I guess maybe if you are zoomed way in it might take more than a couple of swipes? It's important to understand the conditions that lead to problems so we can gauge how likely others are to experience the same issue, and also to understand what the best possible solutions might be.
Here is a screen shot of what I'm working on as we discuss this.
OK, so you are at a size where you can see 5 staves out of 61, and you want to scroll to the top?
I just tried a quick test, and had no trouble doing so in one or two swipes with my current mouse settings. How far does each swipe go for you? For me, a short swipe goes a single screenful, so indeed it would be a chore, but a "flick" (?) of the wrist sends the view all the way to the top or bottom just as it should and does for other programs. Does your driver not provide such an option?
forget it
Marc is notoriously hard to convince. But, I'll just say it: I'm in favor of scroll bars, too.
I am also open to the idea of scroll bars. But I am also truly trying to help here. Right now you are saying you are having difficulty scrolling to the top of a page. I am trying to explain to you how you can do so easily *right now*, no need to wait for developers to implement a new feature. I am honestly confused as to you you seem to be annoyed by this help I am offering.
my mouse works fine
Pressing Home brings you to the top of the score with one keystroke, End brings you the last page, Page Up and Page Down bring to to previous and next page, respectivly. See also https://musescore.org/en/handbook/keyboard-shortcuts#score-navigation
That is not useful in continuous view when you want to move from the last line to the first in the same measure.
I agree, the current shortcuts do not provide a way to quickly move to the top the current page of your score (or equivalent in continuous view). That is, keeping same measure in view, see top staff. Only keyboard-based method that makes works at all for this is Alt+Up to move one staff at a time, and it isn't particularly convenient for this purpose either, because the view stops following the cursor and in avny event would require you to press and hold for a long time. So a new command to immediately move the cursor to the top staff, keeping current measure and repositioning view accordingly, does indeed make sense to me.
I'm sorry, though, but I'm still confused by the statements about the existing mouse hebavior. One one hand it is claimed:
"Right now I sing "Scroll, Scroll, Scroll your mouse slowly up the screen..." every time I move from the strings to the flutes, which is a lot"
But on the other hand, it is also claimed:
"my mouse works fine"
It seems to me that perhaps you don't realize these statements are at odds. With a properly configured mouse, it really does take only one single swipe to reach the top staff, as I observed above. So either 1) your mouse *can* still stand to have its settings tweaked so that it works as well as it should, or 2) your mouse can already do this and you just need to learn the correct gesture for it. Or, much less likely, 3) your mouse is an older model that doesn't support this feature.
Right now I still don't know which of these is the case, and I'm not sure you do either. So I do hope you will help us get to the bottom of this. If it's 1) or 2), we will have performed a great service for you - solving your problem *today*, no need to wait for some future version. If it's 3), then we developers will know that some percentage of users are on systems that don't support the modern navigation models. We can then prioritize possible new features accordingly, as we gain a better understanding of how many users are affected by this hardware issue. So this also benefits you down the road.
Bottom line, I really am trying to help here, but it benefits us all to understand the situation as fully as possible.
Is it really that hard? My gut sense is that something like this wouldn't need developer time and energy so much as a developer to just change a bool somewhere.
I want to chime in here and mention that this is a huge feature for me. I have old hardware running Linux. A laptop with a mouse pad that cannot support side scrolling. And the vertical scrolling of this mousepad is clunky at best. I like a really zoomed in view on one staff while inputing notes. So scrolling horizontally and vertically is very common.
Scroll bars are the EASY way out, relatively simple, and offer accessibility to everyone.
The navigator is no help in page view since horizontal movement is a chore unless the navigator is so big you can actually see the page. The navigator in continuous view is better. Ideally there would ALSO be a "hand" tool, where on key down, the cursor turns to a "hand" and I can drag the score.
I'm tempted to download source simply so I can implement this because it's almost ridiculous this wasn't a feature when it first came out. Even if it is hidden behind an option... Having been a software and user experience engineer for a decade it's almost laughable. Sorry to be that crass. Regardless I am very thankful for this free tool <3 Thank for reading
As to the hand capability, just click and drag on an empty part of the score.
Often if your system seems not to support side scrolling, it does if you hold down the Shift key. But if you're equipped to implement this, feel free, and please make a pull request—I think it's very likely it would be accepted.
Came up again https://musescore.org/en/node/270143
Implemented in MS4.0-alpha
Automatically closed -- issue fixed for 2 weeks with no activity.