Add option to limit scroll area of the navigator and the score view
In MuseScore 1.0 and in the trunk, one can drag the blue rectangle to very far area from the actual score. It would be better to limit the area where the blue rectangle can be dragged.
In the same line, by dragging the score itself, it's possible to go quite far. I should be limited.
This feature request is not critical of course, but it's one of the small details that make MuseScore looks better and be more user friendly.
Comments
I'd like to mention a related issue that maybe of consideration when implementing this.
This issue was brought on by the discussion in this thread: http://musescore.org/en/node/8792#comment-29479
I'm still curious why the score display area appears limitless when dragging (or mouse scrolling) in it. The navigator logically limits your scroll area (most of the times). To me, there should be maybe a 5cm (max) border around the score pages, but not the limitless area that exists right now.
I agree. I brought this up some time ago, but it was in the request to have the score basically pin to the top left corner of the desktop when zooming.
i think this is an import feature that I certainly would like to see implemented.
The main score area should be movable without limit. Think about zooming out of the score. It's very inconvenient, if the cursor position changes relative to the score which is unavoidable if you force the score to move to the top left screen.
I see no benefit in restricting the score position.
I think the main score limit should be more free than the navigator (depending on the way you view score - same could be said in a way for navigator), but some kind of limit so the user can't endlessly drag it off the screen.
Several points to consider:
* Most programs don't present a limitless working canvas. It's asking for usability troubles, esp when scrolling or zooming. Finale certainly doesn't.
* In v1, mouse scrolling can easily bring you into a completely blank area where you don't see any score. If the navigator is off, its very easy to get lost. This is not so much of a problem in v2 because the navigator works better.
* I suspect most people use the navigator, but having a zoom that allows the score display to go down to 5% seems unnecessarily small. The pages are very small thumbnails at that point. Restricing the zoom level to >25% would partially solve this. I _rarely_ go below 50% because the score becomes unreadable. Any score that is over 10 pages should use the navigator.
* Its very important for the cursor position relative to the score not to move when zooming _in_ as you are typically focusing on something to edit. However when zooming out thats not nearly as important. When zooming out and the %zoom causes the dead space to exceed its limits then the display can shift. Finale is annoying because it doesn't follow the cursor either way.
I was not very clear in my previous post, #3.
What I think would work is to keep the present system of using the cursor as the zoom point is important. You zoom in and you see the part you want to see. However, when you zoom out, once the area seen includes the top left hand corner of the score, that is when it should "pin" that corner. Unless I am missing something, I can see no purpose to viewing the desktop above or to the left of the top of the score.
Regards,
I made a patch based on rev 5594 to limit mouse wheel in main score area, I also add 50 px margin.
Let's see if it can improve this issue.
I will vote to add scrollbar for score area, because scrollbar length will also tell user about how big the score is.
It of course can change length when zoom in & out, or just hide when pages is less than score area, then user will feel he/she has more control power.
I commited an improved version of the patch in r5599.
The limitation is applied on scroll and drag of the score view are. I don't see any of the problems raised by Werner in #4.
To be perfect, the navigator should also have this 50px margins and click on the navigator should also be limited. I will let this issue open for the time being.
Werner reverted the commit in r5604 with the following comment :
"too restrictive; it should be possible at least to move the right edge of the score to center of the screen (or top, left, bottom). I do this often before zooming in. I believe there should be no limitation at all. Its irritating that dragging the canvas sometimes work and sometimes not bc. of some arbitrary limitation which is not immediate obvious."
I only temporarily disabled the function to make the latest version usable for me. The restriction really destroys me usual work flow which is very annoying. I make heavy use of zoom in/out with the mouse wheel (heavy recommended btw., even with laptop).
I agree with werner.
I've just downloaded r5603, and am finding the scrolling limits extremely frustrating.
It interferes with the way I zoom with the mouse wheel.
I see no reason why it should be limited in this way - limiting the Navigator scroll is enough.
For the reference, this issue was blogged about at https://simplyrobert.wordpress.com/2015/02/17/musescore-2-0-beta/ :
"The application workspace has no idea what the dimensions of your document are, so you can scroll it to oblivion. Of the interface I’d like to see fixed, this one is at the top of my list."
What about using a solution similar to the commit which was reverted and limit the scroll to the dimension of the document + one full page?
I mean, possibility to scroll to the right up to the end of the score + one full page width; possibility to scroll down until to the bottom of the score + one full page height, and similarly for up- and left-scroll.
I don't know if this is feasible (I didn't check the code), but such a solution could satisfy everyone, since one could drag the score up to the border of the active window, and if she/he gets stuck outside the document she/he can drag the canvas and the border of the score will appear from one side (so she/he can easily go back to the score view).
I slightly modified lasconic's implementation to add a scroll area margin around the score equal to 3/4 of the current ScoreView window's width/height.
The only possible "problem" left could be the scenario in which the user moves to one of the scroll border when the zoom is very small and then zooms in to a very large zoom value; in this case she/he finds herself/himself very far outside the score. However, she/he can only scroll towards the score (scrolling in the direction pointing outwards is prevented by the constraints).
Pull request:
https://github.com/musescore/MuseScore/pull/1788
Fixed in 3fe4a3b1ef
I just tested the latest build and overall it works as advertised. I could also reproduce the open problem as explained by ABL. Here is a video:
So it starts with the right behavior, but as I zoom out and next zoom in again, the score basically drifts away. Not sure how much of an issue that is during real work.
Coming back to my previous comment, the steps to reproduce the issue are as followed:
* zoom out and place the score outer left
* position the mouse at the right of the score
* next zoom in
The further you position the mouse pointer right from the score, the more the score will pan out.
Automatically closed -- issue fixed for 2 weeks with no activity.
I missed the discussion here while the thread was on fixed. MuseScore now constrains the scoreview also when zooming in 15f1850211
I thought what you just fixed was the one area where Werner had real issues with constraining the canvas, and why he didn't like it. The mouse pointer normally maintains focus on a specific spot on the score no matter how far in/out you zoom, doesn't this fix break that focus?
Note, not that I have a problem with this. I've supported the idea but need to build and test.
OK, if you zoom way out till the score is tiny, position the mouse far to the right or the bottom of the score and zoom back in, you will always see the edge of the score. However if you zoom way out again, position the mouse far to the left or the top of the score, you will _not_ see the score edge at all.
@schepers could you make a screencast? I use gratis software named Licecap which makes gif files. This will be very helpful to complement your words.
OK, videos made.
This is zooming out and scrolling back in from the far right and far bottom. Notice how the score is always in view.
This is zooming out and scrolling back in the from the far left and far top. Notice how the score disappears from site, and it truly is a ways away now.
When I first started using MuseScore, I was very disorientated and confused by the huge canvas. I was absolutely puzzled by the fact you could scroll into pointless whitespace. Now, after a couple of years as a MuseScore user, I still find it immensely irritating.
As far as I can tell, his is not something you see with word processors and other document-based apps. Why should MuseScore behave differently?
"it should be possible at least to move the right edge of the score to center of the screen (or top, left, bottom).“
Why exactly, Werner? That seems like an arbitrary statement. My eyesight is quite poor (50-60%) so I frequently resort to zooming when using my computer and I really don’t see how a massive blank canvas helps with inspecting what you are working on.
@RobFog This issue has been fixed in MuseScore 2. If you feel this is not the case, you may reopen this issue and explain as good as possible how you would like to see things improved.
One of many excellent new features in MuseScore 2. ;-) But as schepers pointed out above, if you zoom out until the score is tiny and position the cursor far above and/or to the left of the score, when you zoom back in the score will be entirely out of view.
Thanks for your replies. :-)
Thomas, I have been using MuseScore 2 for a while now and it really is a great improvement over version 1. I checked MuseScore 1 again and you are right that the blank canvas situation is much worse there.
Zooming
For me, zooming is not the primary issue. The zooming OS X provides works fine for me and so does MuseScore’s.
Why place the cursor in the whitespace before zooming? Why not place the cursor near the place you want to inspect more closely before zooming?
My issue: unnecessary whitespace
My issue is quite plain and simple: why should there be excessive whitespace? The border around a page needn’t be wider than the borders separating pages. If the score page (or multiple pages) fits the width of the display, why would I need to scroll sideways (horizontally)?
Again: word processors like LibreOffice or Apple Pages don’t have this massive canvas, why should MuseScore?
See attached annotated screenshots for illustration.
@lasconic and others: should I reopen this issue or file a new one?
I'm habving trouble understanding the problem. If you don't want to have your score at the bottom of the canvas with excessive space above it, why would you put it there? Normal scrolling operations should never result in that happening unless you specifically asked for it, and it doens't for me. I guess if you scroll accidentally with the mouse wheel or something, I could see it happening on occasion, but then it is a split second at most to scroll back. Could you describe in more detail how you are finding yourself seeing cases like this?
Here's a use case for this, though. Suppose you have the Mixer and the Play Panel open. They're blocking part of the main window. If you couldn't scroll this far, you'd be unable to view certain parts of the score without closing or moving windows. I agree that the limitless canvas was a problem, because you could actually lose the score completely, but I don't think it's necessarily a positive thing to restrict the canvas to tight borders around the pages.
I’m not saying this actually happening regularly, I’m arguing that it shouldn’t be possible. And this is would not be an arbitrary limitation.
Why shouldn’t it be possible? / Removing the excess canvas (PRO)
Example : You are working on page 5 and want to check something on page 1. Without the whitespace, you could just keep scrolling freely to the left and you would end up looking at page 1. With the whitespace, you run the risk of scrolling past page 1 and into the whitespace left of it.
Example : You have set the zooming factor so that the page fits the main window vertically. You are scrolling to the right to see the next pages of the score, scrolling only occurs horizontally, there is no vertical movement. Scrolling feels "solid“. (See screenshot "MuseScore #8808 - horizontal scrolling“)
Keeping the excess canvas (CON)
Thanks. That is a good point. You gave me something to chew on, in parts because these extra windows differentiate MuseScore from many word processing scenarios. :-)
„without closing or moving windows“ – or resizing them… When using MuseScore with small screen real estate, the obvious solution would be: make the main window a little smaller, place the the extra windows in the free space. (See screenshot "MuseScore #8808 - extra windows") For frequent use of the extra windows, that is a permanent solution. For rare use of them, a quick drag to resize the main window shouldn’t be too bothersome.
I was trying to understand your comment "I still find it immensely irritating". That to me suggests this something that for some as-yet-unexplained reaosn, you are actually running into on a regular basis, as opposed to siply having some sort of philosphical observation over whether in theory it should be possible or not.
To go quickly to page 1, simply hit Home. Or End to go to the end. So there should not be such concern about scrolling past the ends of a score, and again, even if it happens, you hand is still on the mouse, just scroll back.
Also, FWIW, it is probably more to the point to compare MuseScore to other programs that deal specifically in page layout - things like Scribus, etc - than to think of it as like a word processor.
As to 1., that could certainly very easily happen. I just don't see it as a problem—MuseScore 2 keeps you from actually moving the score out of view, so it's just a little quick scroll back. (By the way, there are keyboard shortcuts that would make going from page 5 to page 1 a lot easier—based on the screenshots I'm guessing you're on a MacBook, so try fn+left arrow key).
2. is a more interesting point. On the other hand, suppose you're zoomed in, not out, when you're scrolling horizontally. There might be some vertical movement then in any case (though I recall a user feeling uncomfortable with that fact, actually).
3. The other thing is, of course, that it's not a common way to do things. Nor, for that matter, is it common that clicking and dragging on an empty part of a page should drag the page around in the view. (Nor is it common that clicking and typing should similarly enter content.) Compared to interface differences like that, this isn't really such a big deal to get used to.
By the way, I basically meant to include "resizing" within "moving windows." To my mind, scrolling is quicker and even less bothersome than resizing the window would be. ;-)
I guess what it comes down to is that it would be just as annoying for me to be unable to scroll past the edge of the page as it is for you that you can scroll past the edge of the page. So, here's an idea: what about an option letting the user choose whether to limit scrolling to (let's say) within an inch of the page boundaries, or to use the current system? (Ideally with schepers' problem fixed.) I see this a checkbox in the Preferences, in the General or Canvas section, for "Limit scroll area to page borders". It could be turned on by default—I wouldn't mind.
Marc, the phrasing "I still find it immensely irritating" was a little over the top, I must admit in hindsight. But I still find the excess canvas annoying on a daily basis – both from a usability and an aesthetic point of view.
With MuseScore’s complexity, it’s hard for me argue my point while incorporating most usage scenarios, I have to say. Another potential compromise I thought of would be to make horizontal und vertical borders smaller but wide enough to accommodate the maximum heights and widths of the extra windows which seem to be around 350-400 pixels. Currently, the horizontal borders are at a whopping 800-something pixels… (This is at a 1280x800 resolution – yep, MacBook, Zack :-) ).
That being said, I’d certainly welcome a setting "Limit scroll area to page borders“ as suggested by Zack. On the other hand, MuseScore has already so many settings, I don’t want to contribute to feature creep. ;-)
Thanks for the tips regarding keyboard shortcuts.
Slightly confused about the "potential compromise"—there is no maximum height or width for those windows. Try clicking the green zoom button and see. But anyway, it's my feeling that adding code to tighter restrict scrolling wouldn't be made more difficult by keeping the old code around and adding one little checkbox to re-enable it. Think about scroll direction on a Mac—how it changed with Lion, but they let you uncheck that checkbox in System Preferences to return to the old behavior. That's where I got the inspiration from, actually.
Yes, "maximum height“ was a bit unclear. What I mean is this: all of these windows seem to have default sizes. My suggestion would be to take the largest widths and heights of these defaults to determine how wide the borders would have to be to accommodate the windows.
By feature creep I didn’t mean code but UI complexity. Too many preferences can make software hard to use.
Well, what do you want? Feature creep, or keeping the current scrolling behavior? ;-) Myself, I'm glad that Apple lets me uncheck that one little box in System Preferences, and I know plenty of people are happy with the new(er) default. New users wouldn't even know about the analogous option in MuseScore, and would be comfortable with the tight boundaries of the canvas. People like me would go uncheck that box once and forget about it. Of course, if you really think it's a bad idea I guess we can leave it alone… but I don't think there's any way it's going to get permanently changed the way you'd like without an option to change it back.
Yeah, I’m still using OS X’s old scroll behaviour as well. ;-)
It’s really not my intention to force my preference on anyone at all. And I do think a checkbox for "tight boundaries" (good wording, by the way) would be great, even if it were to default to the current situation. Just trying mention pro and cons for everything, to be fair… :-)
Fixed, but needs tweaking—be aware of #117331: Allow navigator to scroll above/below page and some inconsistency between the limits when dragging the page and much tighter limits when using the Navigator.
Hi Zack, are you saying this is fixed in the current stable version 2.0.3?
I believe so. Scroll in any direction and it will stop before the edge of the page goes out of sight.
See my comment 25 as the scroll out/in from the top or left side still can put the score out of sight: https://musescore.org/en/node/8808#comment-231406
See https://github.com/musescore/MuseScore/pull/3644
Fixed in branch 2.3, commit 44cdd52d54
fix #8808: Add option to limit scroll area of the navigator and the score view
Fixed in branch 2.3, commit 12a230eeb0
Merge pull request #3644 from mattmcclinch/8808-limit-scroll-area-2.3
fix #8808: Add option to limit scroll area of the navigator and the score view
Fixed in branch master, commit 375c91ca30
fix #8808: Add option to limit scroll area of the navigator and the score view
Fixed in branch master, commit 636ff3f45a
Merge pull request #3647 from mattmcclinch/8808-limit-scroll-area-master
fix #8808: Add option to limit scroll area of the navigator and the score view
Okay, you're all gonna hate me for this, but I feel like the limit is just a wee bit too tight. In LibreOffice, the maximum distance between the edge of the page and the edge of the window is the same as the distance between the edge of one page and the edge of the next—not zero.
Zero distance seems fine to me. :-)
I feel it would make sense to turn this new scrolling behaviour on by default as it's arguably the behaviour users would expect. Pertinent arguments have been made
by @polarbreeze in #68966: Disable horizontal scrolling when zoomed to page width:
MuseScore would then operate consistently with other notation programs, and also consistently with word processing programs. Also the point made by the OP. That would have these benefits: (a) user viewpoint: GUI familiarity for people accustomed to using those other programs; (b) developer viewpoint: building on the usability experience embodied in those other programs (ie not re-inventing the wheel).
by @mattmcclinch in #68966: Disable horizontal scrolling when zoomed to page width:
Providing a way for MuseScore to behave like every other application in this regard seems like the right thing to do.
by @shoogle in #117331: Allow navigator to scroll above/below page:
I personally don't like being able to scroll off the page because most of the time it is not helpful […].
Automatically closed -- issue fixed for 2 weeks with no activity.