Disable horizontal scrolling when zoomed to page width

I don't understand. A wordprocessor doesn't need to scroll horizontally because the pages themselves are stacked vertically. If MuseSccore didn't scroll horizontally, you could never reach any but the current page. Perhaps what you are really looking for is a more vertical mode, then? You can simulate this by setting the page height to be arbitrarily large.

The problem with that is, what if the score is more than one page? MuseScore doesn't display the pages in a single column. But see also #8808: Add option to limit scroll area of the navigator and the score view.

From what I understand, I think the Mac implementation of trackpad scrolling would drive me crazy. Apparently some versions of MacOS have an option to limit motion to exlcusively horizontal or exclusively vertical, but it isn't available on all versions or all trackpads or something? In any case, it does seem to me that this is a problem for Apple to solve, rather than a problem that individual application builders need to solve for them.

I kind of like the scrolling as it is right now on Mac OSX, it follows the fingers very closely. The fact that you can't scroll in diagonal in Safari is very counter intuitive to me.

In term of implementation, there is currently no vector involved, MuseScore just get updates several times during a single scroll move. The update contains relative pixel changes since last update. https://github.com/musescore/MuseScore/blob/2ab95b0cc52ae2af976f2c6d486…

That's because it's quite hard on Mac OSX to have dx = 0, which is exactly the point of your bug report.
But if you press Shift and scroll strictly vertically and slowly in your Mac, you will see that the view is scrolling horizontally.

I realize this is an old post but it relates to a trackpad/mouse usability issue I'm experiencing so I'm giving it a bump. Need a better way to control page movement - currently it's a very uncomfortable experience (IMHO) compared to apps like Finale and Sibelius. I posted a separate feature request on this before I found this thread.

FWIW, the vertical page stacking didn't exist when this feature request was filed. Now that it does, I would agree it would be a nice enhancement to check to see if the page width fits on screen, and if so, not to touch the X coordinate when automatically panning the score. Probably pretty easy, in fact.

Long term, it might make sense would be to add a parameter to adjustCanvasPosition() to give a hint about the desired behavior. The desired pan is likely to be different during note input than during copy and paste, for instance.

FWIW, this happens more or less by default already, except for the bug #271187: Pages jump in Vertical scrolling when the score at the right is partially hidden. When that is fixed, this should be too, unelss someone can come up with another case where it isn't (eg, a case where it doesn't work in 2.1).

Scrolling behavior in the 2.3 branch has changed since polarbreeze bumped this issue on April 7. Now there is more resistance, and the scrolling experience is not as smooth as it was before. Personally, I preferred the previous behavior. I know, you can't please everyone.

Can you give more detail? As far as I can see 2.3 doesn't have any changes over 2.2.1 in this code, so in fact it should behave identically to 2.2.1 - which is to say, it works except for the bug I mention above. If you have some specific use case where you see something different, please give more explanation.

Well, it's scrolling smoothly for me now, so it could have been my imagination. Or possibly other processes running in the background.

Re: "happens more or less by default already"

I see what you mean with respect to auto-scrolling on playback. However, the original topic (and still my issue) is with respect to manual scrolling during regular editing.

In the course of exploring that issue, it's true that I did come across that specific jumping bug but that wasn't the original problem/request.

(I corrected the title of the thread to correspond to the text of the OP's feature request. The title had a typo - it said "horizontal-only scrolling", which is the opposite of what the OP intended)

I am not sure I understand. It's not just playback where automatic panning happens - it's during editing as well. And that's what I am saying that, except for that one bug, I believe this is already good. Are you seeing some other case where there is inappropriate automatic panning while editing?

If by "manual as carolling" you mean you are deliberately dragging the canvas or using the mouse wheel and for some reason are expecting that not to actually work, that is indeed something different. Others have specifically requested the opposite, though, so I'd be reluctant to take this feature away.

I think we're talking at cross purposes. The desired behaviour (as far as I see it, and as also requested by the OP in this thread) is described in the feature request that I posted earlier: https://musescore.org/en/node/270435 - so it's probably better if I refer to that rather than iterate here :)

If the behaviour were as described in that post, 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).

I'm still confused I'm afraid. If I understand that thread - the start of it anyhow - correctly, it sounds like you are are asking for MuseScore to do exactly what I said above - to ignore any deliberate attempts to move the canvas horizontally if the score already fits. Or is there some other aspect to this I am still missing?

Yes, key-notes, thank you, you have hit the nail precisely on the head!

Ok, I understand. I have to say, I have reservations about application developers each needing to build in workarounds for poorly designed input devices - seems the input devices designer should take responsibility and build the into their drivers. But I guess if other applications have been forced to do this, we probably should consider it too.

On a windows desktop, I can't drag web pages around with the mouse. I have to use any applicable scroll bars to move the page. Inside of MuseScore, I can drag the score around with my mouse and place it exactly as I want it, with no left, right, up or down restrictions, which is nice. I'm used to being able to drag things in any directions, so limiting the directions to horizontal or vertical would be a step back. I don't know if this will work with your trackpad, but in most programs holding the shift key will limit the directions of movement to horizontal or vertical, perhaps this would be a good fix/compromise for all devices.

That's kind of my point. A well-designed pointing device would have a way to limit motions to horizontal or vertical only if that's something its users desire. It's kind of a shame they force application developers to address this one by one rather than simply providing a modifier key to constrain motion as other devices do. Would be interesting to see the actual GUI interface guidelines for this sort of thing.

The Apple trackpad is a very well-designed pointing device. Application developers do not need to "build in workarounds" for it, as you say. The problem is that the scroll area in MuseScore is larger than it needs to be, and not just by a little.

Marc, are you saying the situation depicted below is somehow the trackpad's fault?

Here's the reason why there's a relationship between trackpad handling and margin allowance:

One way that users can deal with this situation (ie unwanted diagonal scrolling in legacy apps) is to bias their vertical trackpad movement slightly to the right so that the page is constrained by the attachment to the edge of the window and can't go any further horizontally. That ensures the movement will always be vertical, not diagonal. This may sound odd but actually it's a very natural gesture and quickly becomes subconscious. The trouble is that this approach does not work in MuseScore because of the crazy 75% grey margin around the page - if you bias to the right, the page simply slides out of sight (almost). That's very disorienting as I've said before.

Which brings us to: how about getting rid of that 75% margin, which serves no useful purpose anyhow. Or reduce it to, say, 5%. I think that might go a long way towards solving this annoying usability problem.

If MuseScore hasn't yet been upgraded to properly interpret these modern gestures, shouldn't MuseScore just ignore them until the proper behaviour has been determined and implemented? That would be another way to resolve this. Simple, elegant...?

Note that click-drag of the page achieves a similar result and not suggesting that it be disabled in any way. The gesture that causes this particular problem is the 2-finger horizontal swipe.

Depends. If your trackpad gives you a way to constrain scroll to vertical only - as practically every input device in the world does - then only a user who deliberately chooses not to use that feature would ever encounter this. And then it's the user's the user's own fault. However, if the device doesn't give you a way to constrain scolling to vertical only, this making it too easy to accidentally scroll horizontally when you really just want to scroll vertically - then yes, to mentuabis a very poorly designed input device.

Similarly, if someone built a keyboard where some percentage of the time you typed the letter "T" you actually ended up getting a "G", I'd call that poorly designed as well, for exactly the same reason.

Which "modern gestures" do you mean? I don't understand that phrase at all. Vertical is vertical, horizontal is horizontal, diagonal is diagonal. Has a new direction been invented more recently?

If an input device sends MuseScore a "horizontal" input, then we interpret it as such. If it sends a "vertical" one, then we interpret that correctly you. If it sends a diagonal one - or a quick series of horizontal and vertical ones - why should we not interpret that correctly as well?

I get that a device that is incapable of sending a pure vertical scroll.command presents problems, and we might need to work around that deficiency. But I don't see where modernity comes into it, except in as much that any device that lacks a way to constrain scrolling seems fairly primitive to me.

The way I see it, the pointing device just tells the app what stimulus the user provided; it's the job of he app to determine what their users want their app to do in response to that. I'm trying hard but I find it difficult to see how it could be any other way...?

Examples: 2-finger and 3-finger swipes; there are many.

I wasn't suggesting that Apple had invented a new dimension - that would have much more far-reaching consequences. It might even justify their favourite adjective: "amazing!"

Most modern devices provide gestures - two-finger swipe, Ctrl+wheel, whatever - to constrain scrolling to horizontal or vertical only. That's how it could be another way. So if you want to scroll vertically, you simply use two fingers, hold Ctrl, or whatever. Not sure what's hard to understand about that. It's only the fact that some devices apparently fail to provide this very basic feature that puts app developers in the unfortunate position of needing to implement workarounds.

So if the device only provides horizontal and vertical, how can the user communicate via that device that they actually want to move diagonally?

One-dimensional scrolling is not necessary in a well-designed application. A well-designed application will not scroll the document past the point where it should stop.

Because of this vexing issue with MuseScore I've been experimenting with a helper app called BetterTouchTool - it intercepts the gestures and can block them or modify them (configurable app by app). It goes part way but in its current version it doesn't work with all gestures so it's a poor and incomplete workaround. And it's my understanding that Apple are wanting to tighten this up and will no longer support the API that allows this intercept to happen; meanwhile, the configurable options in Apple's own mouse/trackpad control panel seem to be less and less at each new OS version. (excuse me if I got details wrong there but that's the gist). Conclusion: the app developers need to take responsibility for this or they will be up the creek without a paddle - for example, can't expect Apple to withhold diagonal scrolling from drawing apps just because some other apps don't deal well with a diagonal scroll request.

I never said that a device should not provide a diagonal optIon - just that a well-deserved device would provide horizontal and vertical options in addition to diagonal. This should seem self-evident for exactly the reason we are seeing here: users are annoyed if they can't constrain scrolling to vertical only.

So as I keep saying, we may need to bite the bullet and implement a workaround, but it's unfortunate that the device design makes it necessary for each application to do this itself when really it would be better if the device just supported vertical scrolling natively.

I don't know of any application that implements a workaround for the Apple trackpad. I also don't know of any other application besides MuseScore that will keep scrolling past the edge of the document.

[What happened to the option to delete comments immediately after posting them? Sorry for the redundancy here.]

Try this: open a document in LibreOffice, zoom out, and experiment with scrolling. (Notice when the scrollbars disappear.)

It's nothing to do with trackpad gestures and all the rest of that.

I think it's about the waaaaay too large border around the paper. So getting rid of that border (what purpose could it possibly serve for the user?) would go a long way towards solving this.

Sorry, I'm sure it's a fine device in other respects. It's just that clearly it could be improved in this area.

Even if we provide the workaround that is requested for the special case where the page width is less than screen width, that won't help in other cases where true vertical scrolling is desirable. Like when zoomed in to large ensemble score and you want to move up and down through staves while keeping the same measure in view. Or the converse problem for horizontal scrolling. Like if you are in continuous view, zoomed in to view just the brass staves in an orchestra score and you wish to move left and right keeping those same staves in view.

And the same must surely apply to other programs that present information that has horizontal and vertical significance on a potentially large canvas, like spreadsheets. How to you scroll a large spreadsheet vertically while keeping columns L-R centered in view?

Anyhow, we can go back and forth all day on this but I don't see the point. I get that we may need to do something special for people who use devices with no vertical scrolling support. It's easy indeed to remove the margins - although this will annoy those who prefer the ability to move more freely. And it won't solve the more general problems I described above. But it's something.

It's not that complicated—when a user with an Apple trackpad wants to scroll vertically, they move their two fingers on the trackpad in a vertical direction. When they want to scroll horizontally, they move two fingers horizontally, and when they want to do something in between, they move two fingers in whatever direction they want. Doesn't matter whether in a spreadsheet or in MuseScore—it works automatically, intuitively, exactly as it should. There is no problem we need to solve in that area, no extra constraint that is expected or wanted.

This is about the position of the document in the MuseScore window when it is not larger than the window in one or both of the two dimensions. This is simply a revisiting of #8808: Add option to limit scroll area of the navigator and the score view to improve our handling further.

Yes Isaac, I'd agree that would be the first misbehaviour to correct - I think it would greatly alleviate this problem.

Marc, I don't think anyone would complain about losing the ability to make their workspace look like the image below. On the other hand, I'd be concerned that this behaviour might have been added in order to fix some other bug, in which case that bug might reappear if the margins were returned to normal.

I guess I'm back to being confused, then. If people are happy with moving their fingers more or less vertically and getting the result of scrolling more or less vertically, not minding a slight shift from side to side, then it seems we're done, no?

Sure, we could take away the ability to move the score off to the side, but if everyone is happy with the scrolling facilities provided by their devices, then this change wouldn't actually be an improvement over the already-perfectly-satisfactory scrolling experience everyone is currently enjoying. In other words, trackpads don't enter into this at all. Everyone is already 100% happy with scrolling, some people just also want to remove the ability to move a score off-screen. And I'm back to wondering, why take away something that others (including Werner) have specifically said is useful to them? I thought it was because some people were having trouble scrolling vertically on their trackpads, but it sounds now like everyone is saying this works flawlessly for them.

Marc, with all due respect, this is becoming an extremely frustrating conversation. Just to double check, I went back to Word and Excel and Finale and Sibelius and paid careful attention to how each of them works with the trackpad. They all behave fine and none of them has the issue that MuseScore has. I think if you could lay your hands on a Mac trackpad you would immediately see what the beef is here.

I'm not sure why the Mac trackpad is relevant. This can happen with any input device.

I am sorry that this is becoming frustrating; it is for me as well. I thought I understood the beef, but then Isaac's comment gave me doubts.

My original understanding of the problem was this:

Some input devices do not provide a mode to constrain scrolling to vertically only, and therefore, when using such a device, there end up being many occasions when you are trying to scroll vertically but there is a slight horizontal shift as well. Of the many cases where this could potentially be an issue (and I listed but a handful), there is one specific case where application developers can implement a partial workaround for this limitation: they can make it so that horizontal scrolling is disabled if the page width fits on screen and vertical stacking is enabled. With this workaround in place, any "more or less vertical" scrolling motion to be interpreted as truly vertical in that particular case.

I have no doubt some application developers have chosen to implement such a workaround. Doesn't help with all the other cases I mentioned, but helps with that one special case, no doubt. And I agree we could at least consider doing so too. But it does come at a cost, which is the loss of the ability to position a score off-screen as desired. While this might not be important to you, see [#88o8] and other discussions to understand why some people do value this.

So I am just trying to to be as clear and objective as possible on the tradeoffs here. Who would be impacted positively, who would be impacted negatively, and how to put relative priority on these concerns.

The reason Apple trackpad is relevant is that virtually every other pointing device I am familiar with already provides a native solution for vertical-only scrolling. So whether the page width fits within the screen or not, you can already get perfectly vertical (or horizontal) scrolling. As far as I can tell, it is primarily people using devices that lack this function who find their scores drifting left or right when they are trying to scroll vertically - for everyone else this simply does not happen.

Marc, it's true that some diagonal-capable devices include a vertical-only option to support legacy apps. But this discussion is going in circles. How about just solving the too-wide-margin problem for now - that will help a lot and is uncontroversial because it's obviously broken now. So if MuseScore can simply be persuaded to stop doing this (see below) a lot of people will be much happier - and nobody will be disappointed. Win-win?

As I have explained, taking away this behavior is not uncontroversial. As you can see by reading #8808: Add option to limit scroll area of the navigator and the score view, Werner has explicitly insisted on why this feature is useful, and I know valid use cases have come up in other discussions as well . So I am not going to be the one to argue for removing this feature, but nor am I going to be the one insisting it remain. I am only interested in fully understanding the tradeoffs involved, and I think at this point this has been achieved. It basically comes down to deciding whose needs are more important here, and I'm not in any position to make that call, so I will let others worry about that.

Isaac, to clarify for Marc: you mean that any pointing device can create a situation such as illustrated here, right? Or if you meant something else, could you please expand on that?

Well, that was 7 years ago - Werner, are you still on here?

@polarbreeze Yes, that is exactly what I mean. It's nothing to do with the trackpad—it can even happen just by dragging the canvas.

@Marc: As I understand Werner's explanation, he only needed to get the edge of the page to center of the window because of #181861: Pinch/spread to zoom uses wrong centerpoint, which is now fixed.

In case you aren't aware, Werner is the person who created MuseScore and is the lead developer, so yes, he's still around.

As for the image shown - yes, of course, any pointing device is capable of moving the score off-screen like that. My point - which I would have thought should be clear and non-controversial - is that for most devices, this would only happen if you deliberately chose to do that, because vertical scrolling is always completely reliably 100% vertical on most pointing devices, regardless of the width of the page. Only on devices that don't provide a constrained vertical scrolling mode would cause you to sometimes drift left or right when you are just trying to scroll vertically. So the fact that it is possible to create that image in no way interferes with one's normal use of the program whn using a conventional pointing device.

There is no danger with my touchpad, for instance, of inadvertently moving horizontally while scrolling vertically, because one operation involves holding Shift and the other does not. So people with a vertical-constrain mode simply don't find themselves accidentally getting into that situation. Similarly, on my touchpad, in continuous view on an orchestra score and the view zoomed to show the brass staves only, I can scroll horizontally 100% reliably, no danger whatsoever that the tuba part will drift off the bottom of the screen because my mostly-horizontal drag was accidentally a little vertical as well. The staves stay absolutely locked into place vertically, not moving by even a pixel. It's quite a nice feature, this constrained scrolling.

Anyhow, again, I get that people who have devices that lack this feature would want MuseScore to provide this workaround. It doesn't solve the other problems caused by lack true constrained scrolling, but I totally and completely get that would it would in this case, at the cost of removing a feature that some have said they find useful.

So if it is indeed the fact Werner no longer values the feature of being able to drag the score offscreen in this way, and no one else does either, I have no problem supporting a change to remove that feature.

Thanks Marc, that's great news!
So what's the procedure for getting this change implemented?

Description: reduce left, right, top, bottom canvas margins to 2% (currently 75%)
(2% value is up for discussion: practically it could be 0% but 2% maintains the illusion of white paper on grey background)

It would be desirable at the same time to implement the full feature request found at the link below; however, pragmatically I'd be happy with just the margin fix for now - just speaking for myself of course.

https://musescore.org/en/node/270435

The thing to understan. Still is the right behavior when zooming - that's the whole.reason we allow the wide margins now, as explained in #8808: Add option to limit scroll area of the navigator and the score view. Zoom way in, place measure 1 at the center of the screen, now zoom way out. Currently measure 1 stays in the middle of the.screen, this yielding wide margins. .tonne, and apparently to Werner, this is a good feature. What is needed is a plan to not disrupt this.

Yes, I can see the value of keeping the target measure in sight.

I just checked and:
1. Currently the target measure doesn't actually stay in the centre of the screen when you zoom out but MS does try to keep the target measure visible in the window - the target measure seems to end up at the edge or corner of the window.
2. When zooming right out, it appears to temporarily ignore the 75% limit, if it needs to in order to keep the target measure in the window. Therefore the same logic would presumably ignore the new, smaller limit in the same way.

So I think it should be all good in that respect - but it should be easy to try. Somewhere in the code there much be a few instances of "75%" that could be changed to "2%" for a trial...?

Sure. It's in ScoreView::constraintCanvas(). It is a simple matter to change the two instances of 0.75 to a smaller value, or even take out the call to pagesRect.adjust() altogether.

Target measure does remain in place when zooming out if you use a gesture-based zoom method. Not sure what your trackpad might support, but on most touchpads as well as touch screen, it's pinch. Works very nicely and I'd be very reluctant to give that up. And that's but one of the use cases that would be compromised if we removed this feature.

Oh, OK, yes, I see what you mean with the pinch - I was using the dropdown zoom settings and it does not work with those. Very nice feature by the way, I can see why you wouldn't want to lose that.

But it's not obvious to me why this zoom feature would be broken by reducing the canvas margin to a small value. I've played around with it and as far as I can see, the pinch-zooming ignores the canvas margin limit. If we could just somehow try it with the smaller values we could know for sure.

There is a way to try it with the smaller values. It involves compiling from source, which I would recommend to anyone who is interested in the development of MuseScore.

The code that handles zoom uses that same constrainCanvas() function. I already tried reducing the margins and it breaks exactly as predicted. Even if we removed the constrainCanvas() call from the zoom function, what if you try slightly adjusting the canvas once zoomed out?

Awesome! I'm not able to compile but maybe some other Mac user with an interest in solving this problem would be able to do that? Any volunteers? :)

When you say "breaks", what does it do/not do?
It looks like the zoom was a quick-and-dirty implementation and those humungous margins were a quick fix to make it work - is that what we're dealing with? What would it take to go back and do a clean implementation of the zoom function?

I suspect that the people who are frustrated with the size of the scroll area would not mind the way that this change affects zooming. And the people who are most concerned about zooming don't mind so much the size of the scroll area. It seems to me that the user should be able to decide which they value more. I am still trying to figure out the best way to present this as an option.

Well put, Matt
But I don't think there's a fundamental reason why they need to be mutually exclusive. The conflict is only in the way MuseScore has implemented the zoom feature isn't it?

The zoom feature has been implemented the way it has in order to place the score precisely where it does. This is what some people want. Others might like to see the score kept centered in its container window when zoomed out far enough that the entire width or height is visible. So I would say that they are mutually exclusive.

What breaks is the focus point no longer stays pinned, and you see the dreaded "score jumping" that elsewhere you are so concerned about. This has nothing to do with how MuseScore has implemented zoom - you can't change the laws of physics. If you wish to keep a measure pinned to the same location as you zoom out, this absolutely necessarily means there will be a margin around the page once the page gets small enough. If you artificially force there to be a smaller margin, the measure will focus will necessarily drift toward the edge of the screen as you zoom put to prevent the margin from exceeding the artificially forced maximum. It can't be otherwise, just common sense.

One way to provide an option is via a simple setting in Edit / Preferences to set this maximum margin. The default can stay as it is for the benefit of smooth zooming. Those who lack vertically-constrained scrolling ability on their input devices can then choose for themselves to sacrifice smooth zooming in order to get more consistent scrolling in this specific case where the page width fits on screen.

I thought we had finally agreed that this has nothing to do with input devices. Furthermore, it concerns not only the case where the page width fits on screen, but rather any time any edge of the score is on screen.

I don't find the current zoom out behavior very smart: yes it keeps the "focused" measure more or less on the same place on the canvas, but this is only a good design when you zoom in.
Zooming out makes that when the zoom level would allow to see the complete score, instead of that you get half the canvas grey and half the score visible.
Before zoom out:

After:

If I am truly focused on the first measure, this is as I'd like it. I don't want the thing I'm focused on moving unnecessarily. Then also when I zoom back in, it stays where it belongs. Zoom out, zoom in, zoom out, zoom in, my focus point remains the same. This is good. If I want to pan the score to see more of it when zoomed out, I'll do that myself, which is also easy enough.

As for the extent to which input device plays into this, I guess we will need to agree to disagree. As a person who has never used MuseScore with an input device that did not support vertically-constrained scrolling, I have a hard time understanding the desire to not be allowed to scroll horizontally whenever I so choose, and as I have been explaining, the ability to have wide margins is very important for a good zooming experience. I personally would see zero value in making that trade - no, scratch that, it's a negative value.

If others feel differently, regardless of input device, fine, let them set the margins smaller if we provide that option. It still seems patently obvious to me that people whose input devices lack vertically-constrained scrolling would have more incentive to make that sacrifice, but no doubt at least some people who do have vertically-constrained scrolling would for whatever reason still wish to do this.

Re: "Those who lack vertically-constrained scrolling ability on their input devices"
I've found an ancient Apple wireless wheel-mouse gathering dust in a junk drawer. So I can use that old clunker for MuseScore - and reserve the Magic Mouse for apps that are more in tune with its dashingly diagonal personality. Unfortunately I don't have a way of downgrading the trackpad to vintage-vertical so this is not a complete solution.

Kidding aside, I get the point - if you want to zoom in without moving the focus point there has to be space there to start with for it to zoom into. Hmm, need to think about that...

I have made a pull request to add the option suggested by Isaac Weiss and polarbreeze. See fix #8808: Add option to limit scroll area of the navigator and the score view. I am very happy with the result. Maybe we can finally put this issue to rest.

Marc, does this represent the use case for the zooming thing?

FIGURE 1: 100% zoom

FIGURE 2: 300% zoom

What we have here is a measure in the worst-case position, ie the first measure in a system (worst-case because measures further from the edge have much more room to grow before they encounter the edge of the window).

This illustration shows that this worst-case measure can enjoy a 300% zoom with only a 20% margin.

1. Is this a correct portrayal of a zoom-fancier's typical requirement?
2. What is the use case that requires a 75% margin? I find it hard to visualize.
3. Is it possible that the margin was supposed to be 25% but it got coded as 75%?

Great, Matt, thanks!

Supplementary question: what is the required zoom behaviour if the measure of interest is the one selected in this screenshot?

No, sorry, that misses the point entirely. I'm talking primarily about zooming out, although indeed one reason keeping the focus point pinned is to facilitate zooming back in again.

So, start by reversing your two pictures - say the user starts with the 300% zoom picture, then chooses to zoom out. Let's further say he is specifically focused on the Db at the end of the measure, and delibrately puts his fingers on the touch screen right in the exact spot and then starts pinching. The correct behavior is that the Db stays right there under his fingers as the view zooms out. But if we look at your zoomed-out picture, we see the Db has drifted way to the left - not what the user asked for at all. In order to keep that Db under his finger, we'd need about a 50% margin, especially if he then continue to zoom out further.

And this is but one use case where a user might legitimately want a large margin. Another is to create a "dead" to overlay under window - I do this sort of thing all the time. Whether it's the Mixer, Play Panel, or another program entirely (say, view of a PDF I am working from, or a document between which I am copying and pasting text and images).

So again, there are valid reasons to allow a user to create large margin if he wishes, and these are but a few examples. And to me, it is more important to allow the user to do what he wants than to prevent him from accidentally doing what he doesn't want, if the two are in conflict. If it's possible to achieve both, great.

Re "create a "dead" to overlay under window"
Why would you want to reduce the working area in the primary workspace when you can position those secondary windows completely (or partially) outside the main window?

The current patch under review presents a choice of a 75% margin or no margin at all. I don’t really see the need for anything in between.

Don't you think that all these problems could be fixed by keeping the current freedom of margins and zoom behavior,
and adding, as an option, the possibility for users to display and use scroll bars if they want to?
I know scroll bars of MuseScore have been excluded to win space on the canvas and that we are supposed to use more "modern" ways to scroll,
but personally I missed them and in the way I work scroll bars would be a lot easier to navigate.
Plus, scroll bars would enable "vertical only" and "horizontal only" movements whatever is the pointing device.

Re: "delibrately puts his fingers on the touch screen right in the exact spot and then starts pinching"
So does this zoom-in-place feature only work with a touch screen? I'm gradually piecing the picture together.

How far would the user typically want to zoom out? Are they happy when the page gets down to the window size or do they want to go further than that?

No, it's not just touch screen - same for a standard touchpad, or any other pointing device that allows one to specify a particular focus point when performing a zoom gesture. As for how far one might want to zoom, different situations call for different zoom levels - otherwise, we wouldn't bother providing the feature at all. Wanting an entire page to fit vertically is quite common though.

As for overlaying windows versus placing them side by side, I prefer to keep MuseScore maximized, personally.

The point is, there are different ways people have of working, and allowing them to do as they see fit is generally a good thing. Trying to second-guess what they might not want to do then artificially preventing them from doing it is seldom a good strategy.

Scroll bars would indeed provide another workaround for people whose input devices lack a true constrained scrolling option, and they also solve the more general problem these people might have in cases where the page does not fit on the screen (the example I have mentioned of wanting to keep a given set of staves fixed in place vertically while scrolling horizontally in continuous view - an extremely common use case for many people).

But that's a discussion for a different thread. This one is more than long enough already! :-)

<< It's much easier to swipe on the trackpad >>
This is your opinion, not mine.
And with a desktop and an ordinary mouse, scrolling in a big score without scroll bars is extremely pain full.
MuseScore is the only application I know that doesn't offer me the possibility to use scroll bars.

Re: "The point is, there are different ways people have of working, and allowing them to do as they see fit is generally a good thing. Trying to second-guess what they might not want to do then artificially preventing them from doing it is seldom a good strategy."

I agree with that. In fact that's what this whole thread is about - users complaining because they're NOT able to do as they see fit!

Is there anyone on the development team who uses MuseScore regularly on a Mac?

"In fact that's what this whole thread is about - users complaining because they're NOT able to do as they see fit!" - well no, rather the opposite.

I meant something very specific by my statement. I think if a user initiates an action that is designed to have a specific effect, it should have exactly that effect, without the application artificially preventing it from working that way because the developers though maybe the user wouldn't have really meant to do that. So if a user initiates a "vertical scroll" action, MuseScore should scroll vertically, if a user initiates a "horizontal scroll" action, MuseScore should scroll horizontally, and if a user initiates a "diagonal scroll" action, MuseScore should scroll diagonally. Simple as that. "Do what I say, not what you think I might have really meant".

What this thread about is preventing a user from scrolling diagonally in certain cases even though he is actually moving his finger diagonally, because at least some users some of the time might not have meant to scroll diagonally.

Now, don't get me wrong - sometimes it does make sense to prevent users from doing certain things that clearly don't make sense - to protect them from their own mistakes. There is nothing wrong with a little "do what I mean" in interface design. The trick is to do this in ways that don't also get in the way of things you might legitimately want to do. And that so far has been the rub here. Step one, though, is to recognize that this is the tradeoff we are talking about. Only then can we figure out how to prevent the first group from shooting themselves in the foot without also preventing the second group from hunting rabbits.

?? I am not sure I've ever used a mouse during the many years I've used MuseScore, not sure where you got that idea from. But FWIW, the last mouse I did use (probably back in the early 2000's) provided both vertical and horizontal scrolling options. On the other hand, I do recall using a Thinkpad-type device back in 1990's with the little "pencil erase" type of pointer, and as far as I recall that provided neither, so that is the one device I do have experience with that would suffer this same limitation.

What I have used almost exclusively for the past decade or so is the normal touchpad that is included with almost every laptop. I've used dozens of them, and not a single one failed to provide both horizontal and vertical scrolling options. Some via dedicated scroll zones along the side, some via two-finger swipe gestures either horizontally or vertically, some via vertical two-finger swipe with or without Shift. But again, every single device I have used with MuseScore provides these options, making it perfectly simple to scroll horizontally or vertically with 100% reliability.

So to summarize, both vertical and horizontal scrolling are basic features of virtually every pointing device I have used over the past 20 years or so. I'm not sure where you get the idea I am "blaming users", but it is true that it still boggles my mind Apple would have omitted such a basic feature, and I truly wish they'd consider a simple driver update so that, for example, holding Shift would constrain to vertical or horizontal.

In any case, what's done is done, and indeed, we need to deal with it. But again, hopefully without preventing users from being able to move the canvas as they see fit when they so desire. The proposed solution only helps in the special case where pages are stacked vertically and the page width is less than the screen width, which is better than nothing but unfortunately still leaves a great many situations where one might want true vertical or horizontal scrolling but can't get it. So to me it's incomplete at best, but so far the best compromise that has been found.

key-note: +1 for "This incidentally isn't an issue for any other Mac software I use."
Word, Excel, Pages, Finale, Sibelius etc etc all face a very comparable GUI issue and they all support the same variety of pointing devices. I don't have to go to their forums to beg and plead for them to fix their user interface - because it already works the way I expect it to, in all those cases.

I don't seem to have much trouble with scrolling vertically on an Apple trackpad in MuseScore. But I hardly ever require a true vertical anyway. Or a true horizontal, for that matter. It can be off by a little, and it wouldn't matter a bit. But when it keeps scrolling past the edge of the score, that is when it becomes a problem. So the way I look at it, for me anyway, the proposed patch is a complete solution. But I would love to hear from other Mac users about whether or not this is the real issue here.

The reason this is not an issue in other applications is because other applications do not allow scrolling past the edges of the document. It is not because these other applications have implemented "workarounds" for the Apple trackpad, nor that they decide that the user really meant true vertical instead of slight diagonal. Providing a way for MuseScore to behave like every other application in this regard seems like the right thing to do.

I'm looking forward to trying out Matt's changes. :-)

I can make pull requests all I want, but I do not have the ability to merge my changes into the official MuseScore codebase. Usually @lasconic does that, if he likes the changes. Sometimes he won't, and that could be for any number of reasons.

Oh, no problem. I see there are quite a few pull requests ready and waiting to be committed. I'm sure Nicolas will get to it soon.

FWIW, see also #117331: Allow navigator to scroll above/below page for another discussion of why people specifically want the ability to scroll a page largely off-screen.

OK, I see. So this is for people who like to have their window more or less full-screen, which leaves no external space for the palettes. So they want to slide the page out of the way to make free space within the window instead - otherwise the palettes will obscure the page.

The proposed patch does not take that ability away from those who want it, but rather it gives people the ability to choose whether they want scrolling to stop at the edge of the score or not.

@shoogle said it perfectly: "I personally don't like being able to scroll off the page because most of the time it is not helpful."

I get that many people do not agree with the above statement, but I daresay a great many people do.

Indeed, I was not pointing out that discussion as an argument against the PR, just as an additional point of reference should further discussion become necessary.

The “Limit scroll area to page borders” option is now available in 2.3 and master, and should be available in a nightly build soon, if not already. It is located in the “Scroll pages” section of the “Canvas” tab in the Preferences window.

Yes, it's available in today's nightly 2.3 - I've tried it and it works just the way I was hoping - in both horizontal and vertical scroll; and in both page and continuous view; and with both trackpad and magic mouse. Well done Matt, thank you so much, great job!

so we can mark this fixed?

Not sure what your procedure is - it looks fixed to me but mine is just one opinion :)

Yep. We may notice room for improvement the longer we test this feature but I would consider this issue fixed for now. Great work, Matt!

Thanks, Matt! There is one case, however, I think now is behaving unexpectedly. If you zoom in on a spot, then reset zoom by pressing ctrl + 0 or using the drop-down list in the taskbar, that spot will remain centered. The page will then be cut off as if the margins were still wide. The first subsequent moving action (using scroll wheel, click and drag, etc.) will reset the page, but I still think it should be done together with the reset of the zoom level.

Thank you for testing this feature and reporting this issue. I have created an issue in the tracker, and have submitted a patch to fix this.

Thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.