Add view mode that pins the page location in the window

• Mar 17, 2018 - 23:08

Currently there are two options available in the view dropdown: Continuous View and Page View

The request is to either:
(a) Change the behaviour of Page View to that described below; or
(b) Add a third option (named something like "Pinned View") that behaves as described below

Functional description:

  1. When Vertical scroll preference is selected and the page is wider than the window, the horizontal movement of the page should be restricted to only show a very small grey window border on either side of the page. This is unlike the current situation where it's possible to scroll the page far to the left or right, creating a large empty expanse of grey window background.

  2. When Vertical scroll preference is selected and the page is narrower than the window, the page should be pinned horizontally in the centre of the window and cannot be scrolled horizontally from there. This is unlike the current situation where the horizontal movement would be (almost) unrestricted.

  3. When Horizontal scroll preference is selected and the page is taller than the window, the vertical movement of the page should be restricted to only show a very small grey window border beyond the top or bottom of the page. This is unlike the current situation where it's possible to scroll the page far up or down.

  4. When Horizontal scroll preference is selected and the page is shorter than the window, the page should be pinned vertically in the centre of the window and cannot be scrolled vertically from there. This is unlike the current situation where the vertical movement would be (almost) unrestricted.

The images below illustrate cases (1) and (2), which are the same as MS Word behaviour and other comparable programs. Cases (3) and (4) are similar, but with horizontal and vertical flipped.

Screen Shot 2018-03-17 at 18.57.46.jpg

Screen Shot 2018-03-17 at 18.57.12.jpg

Screen Shot 2018-03-17 at 18.33.19.jpg

Comments

• Apr 5, 2018 - 01:00

Oh boy, this is totally driving me crazy the way the page leaps about all by itself. It's been several weeks now I've been trying to get used to it but I just can't. It totally spoils the user experience. At least can we have a way to stop it jumping autonomously when I do a copy-paste, things like that. Not asking for anything special - just for it to behave similarly to other page-oriented programs. Or is there some magic switch that I haven't found? Or a different way to configure it so it's not so obtrusive? I guess other people have found ways to live with this - can anyone give me tips? Would be much appreciated!

Reply

• Apr 5, 2018 - 05:56

"Oh boy, this is totally driving me crazy the way the page leaps about all by itself. It's been several weeks now I've been trying to get used to it but I just can't. It totally spoils the user experience. At least can we have a way to stop it jumping autonomously when I do a copy-paste, things like that."

Please attach the score demonstrating this (and by explaining with precise steps - when, where, how - what you are doing) rather images, unusable for testings.

Reply

• Apr 5, 2018 - 13:26

Hi cadiz1, thanks for the response. The attached video shows one example. I'm copy-pasting a single measure from one side of the page to the other. The whole page jumps almost the full window width. The desired behaviour is for it to stay in place all the time unless I decide to move it - the same way other similar programs work. This is only one small example - there are many ways in which this odd behaviour disrupts the workflow. Thanks for looking at this, I appreciate it.

Oh, wait, it won't let me upload a video. So, I'll try to describe. In the attached score, arrange the score so that it is slightly larger than the window, with the window cutting off a small piece of the right side of the page. Then copy-paste a measure from the left side of the page to the right side. Result: the whole page moves all the way over to the left side, hiding most of the page. Then you have to drag the page back to where it was in order to continue the work.

This part: "with the window cutting off a small piece of the right side of the page" is the important part for replicating the problem. And because the page seems to move about all the time when you're editing a score (I wish it wouldn't do that!!), this condition can occur in a way that appears random.

I described the desired behaviour in detail in other posts, with images - it's the same way Word and Finale, Pages, Sibelius etc work.

Thanks!

Attachment Size
test Chain of Fools.mscz 24.35 KB

Reply

• Apr 5, 2018 - 15:25

"Then copy-paste a measure from the left side of the page to the right side."

It would have been useful to specify which measure you are copying and the measure of destination (second page)
I do not know yet if that's what you notice: but by removing the line break measure 71 (ie the first one of the second page, which runs the full length of the staff ), do you observe, so after the deletion of this line break, the same behavior?

Reply

• Apr 6, 2018 - 21:47

I think actually this must be a bug - according to Marc's description, the behaviour should be only to move the page a short distance - enough to keep the target measure on the screen with a 5% margin. That is definitely not what's happening here.

Related: it would seem that the vast expanse of grey emptiness around the pages is also a bug. And if it were not there, this bizarre jumping behaviour would be greatly reduced. So two aspects of the same bug maybe?

Would the extent of that grey border be configurable by any chance?

Reply

• Apr 7, 2018 - 22:38

Hi Mike, your profile says you're on Windows 10, just wanting to confirm that - to eliminate the possibility that it could be Mac vs Windows (I'm on Mac).

Also, would you be able to confirm that the mode of jumping around is the same as the one I'm seeing. In the "paste measure 2 to measure 9" test I posted in this thread - do you see the same symptoms? Thanks!

Reply

• Apr 8, 2018 - 14:23

OK, thanks Mike. So the latest view is that it was not an issue with 2.0.3, or 2.1. It is a bug in 2.2, which was fixed in 2.2.1. Is that consistent with what you see? I don't know what version(s) you've tried.

For me, I've confirmed that, yes, this particular jumping is fixed in 2.2.1 - however it was just one of the issues I was having so I'm doing some more investigation now.

Reply

• Apr 8, 2018 - 14:38

I haven't tried any release after 2.1, but I have a nightly from mid march that I use for most of my work. I'll upgrade to 2.2.1 when the alert comes out and probably live with the ridiculous wild jumps that happen in continuous view until the 3.0 alpha comes out and MuseScore stops recalculating and redrawing the score every time you add a staccato to a note. At that point I will start a campaign to fix anything having to do with these wild jumps that still exist.

You have made more progress than anyone I've seen over the past few years. I usually just get a response form Marc giving the company line and finally give up since he won't do anything about it and no one else seemed interested. You actually managed to get someone else to respond. Hopefully that means something will finally be done about at lease some of the ridiculous jumps the screen makes.

I don't use page view until I fine tune the line and ornaments, so much of what you have described I haven't seen.

Reply

• Apr 8, 2018 - 20:39

That's really unfair, Mike.

I am not merely "giving the company line". I always make an honest effort to both understand the problem being perceived and to explain the intended behavior, and to see if there is room for improvement. If all I have to go on is a vague statement about the score jumping, there is little I can do. But in the case at hand, the OP was able to show a very specific reproducible case that clearly the behavior is counter to what is intended, and I myself - not "someone else" - took the time and trouble to investigate and debug the problem. And I have done the same many times before when people have been able to give clear and reproducible steps to demonstrate a particular problem. If you check the records on the source, you'll also see that I myself have fixed several of these issues.

So if, instead of giving up, you would be willing to similarly show specific cases where the re-positioning MuseScore does is objectively and demonstrably "ridiculous" and not simply an honest difference of opinion about what the most desired behavior is, I am just as happy to help in your cases as in any other.

Reply

• Apr 6, 2018 - 18:37

FWIW, I don't think a third view mode is the way to go. I personally wouldn't want MuseScore to not try to help me avoid unnecessary adjustments - I appreciate what it does to keep what I am working on in focus, and to the extent I find it annoying, it is when it fails to reposition (eg, on Undo, as discussed elsewhere recently).

But if I di decide I'd rather do all motions myself, I think the way I'd want to do that is with a checkbox / toggle, akin to the one for playback on the toolbar. In fact, wouldn't bother me to see the same toggle used for both. It would be trivially easy to implement, also, because the repositioning is done entirely (?) in one function so we'd only need to check the status of the toggle in that one place. Actually reusing the existing pan toggle makes it a two-line change at the top of ScoreView::adjustCanvasPosition(); otherwise it's that plus implementing the GUI. As mentioned, this would drive me crazy, but if others like it, it could be a solution.

Reply

• Apr 6, 2018 - 20:28

If you have the ability to build MuseScore from source, I'm happy to tell you the two lines to add. Otherwise, though, probably not practical.

I rather doubt anyone would find they like the result in practice. I suspect the number of times the canvas motion works exactly as desired and you don't even notice how well it's working dwarf the number of times it gets in the way, and you'd instantly notice if the more common useful motions suddenly stopped. But you never know, different people have different preferences indeed.

Reply

• Apr 6, 2018 - 18:59

Hmm, do you think the behaviour I'm showing in those images is actually an unintended misbehaviour of the repositioning algorithm? The action was to copy the contents of measure 2 over to measure 9. Both of those measures are fully visible at the start of the action. However, the pasting action causes the page to leap alarmingly all the way over to the left, so that the left side of the page is no longer visible, and the window is mostly occupied by useless grey space. Hard to imagine that could be desired behaviour...?

Reply

• Apr 6, 2018 - 20:26

The idea is to try to position the page so the target element (in this case, the measure you pasted) is fully on screen - plus a margin (5% of screen width) - if possible. When not possible, or if the layout changes after the operation so the originally-calculated position is no longer valid, that's another matter. No doubt there are cases where the algorithm could be tweaked further though. Probably you'd find working in Continuous view more suited for this type of work though - then the line breaks wouldn't be an issue.

Reply

• Apr 6, 2018 - 21:19

Ah, yes, I can see that 5% margin happening when I play around with it. But it's not clear to me why it has to transport it all the way over to the other side of the window, which is really disorienting.

I must say that I find losing sight of the source measure very uncomfortable - especially because Undo unfortunately doesn't put everything back the way it was.

Re Continuous view - I don't think it's the line breaks that are causing the problem - I removed them all and it still behaves the same way. And with Continuous view I don't get to see the "shape" of the page as I build the score.

Reply

• Apr 6, 2018 - 22:27

Hi Mike, I'm happy to find that I'm not the only one experiencing this crazy-making issue! Please check out my latest post in this thread. The cause is probably the extremely large canvas (grey) border (75% of the window size!) that MuseScore implements. If that border were reduced to, say, 5% or even 2% or 0%, that should solve or at least greatly reduce, this problem.

Or maybe it's user configurable but if it is I can't find the knob to turn to fix it.

Reply

• Apr 6, 2018 - 23:48

It moves all the way to the left because as I mentioned, it's the same code used everywhere, and that includes normal note entry. In which case, this is pretty much exactly what you want - you're typing notes, view stays the same until you reach the right edge of the screen, then it moves all the way left to give you as much room as possible. If it didn't move as far, it would have to move more often. I think most people would find fewer jumps better than more if it can be helped. But indeed, there are cases where this makes sense and cases where it doesn't, and situations where depending on how things line up relative to the page margins, results might be unexpected. I still suspect you'd be shocked at how often this just works seamlessly and how much you'd miss it if it never moved, and so I personally would rather focus on improving the algorithm than disabling it.

Line breaks are part of the problem if not in this specific case because they influence how often what you want s going to be offscreen - now there is a vertical as well as horizontal component to this.

Reply

• Apr 7, 2018 - 02:11

I guess we have different workflows. If I'm typing a series of notes that are going to extend onto the next line I normally want both edges of the paper to be visible anyhow because of the comfort of glancing at where I'm going and where I'm coming from. Such as keeping track of where I am in a phrase that I'm developing, things like that. I don't want the paper to move because in real life paper doesn't move by itself. Maybe I'm old fashioned :)

I agree with you on the focus to improve the algorithm. The first question I have is: why does MuseScore allow that huge margin of empty grey window area around the paper? It can be up to 75% of the window size in each dimension and I don't see what purpose it serves. Am I missing something about the way this is meant to be used? What if the algorithm were changed to only allow a small margin, say 5% of the window?

Reply

• Apr 7, 2018 - 02:43

Having "both edges of the paper to be visible" isn't possible if they are on different lines - especially if one is the bottom of one page and the other is the top of the next. Only in the very special case where there is always exactly one system per page does that make sense. Hence my comment about the relevance of line breaks and why Continuous mode can be better for this.

In real life, you have a workspace big enough to hold a ful sheet of paper and more, whereas this is seldom true with computers, so that analogy unfortunately doesn't hold very well. Imagine if you had to move your paper every time you want to move from the left side of the page to the right and how frustrating that would be - and that's exactly what we are talking about here.

As for why MuseScore allows you to move your score almost all the way out of view, I vaguely recall Werner mentioning some reason for it, but anyhow, it seems harmless - if you don't want to move your paper that far, then don't.

Reply

• Apr 7, 2018 - 04:12

Marc, what kinds of scores are you typically working with? It just occurred to me that if we're writing different kinds of scores our workspace needs could be very different. Maybe you're writing full orchestral scores for example? Whereas I'm doing mostly piano charts or small combos, or even just lead sheets. Just trying to figure out the reason for the different points of view.

Reply

• Apr 7, 2018 - 12:58

I don't want the score to move off the screen and so of course I don't intentionally do that; however, MuseScore moves it off the screen automatically - suddenly and unexpectedly. That is extremely annoying. I want MuseScore not to do that. Do you follow me now? I am in no way suggesting a change to the behaviour as experienced by other people - the feature request was for a user configurable option. The existing functionality would remain as-is.

Reply

• Apr 7, 2018 - 13:42

I think I follow you, but I don't recall encountering cases where that would happen, so I assumed you meant it was something you were doing yourself. Indeed, if there is a situation where MuseScore is doing this by itself, it sounds like a bug. But I guess I'm not entirely sure I understand.

Reply

• Apr 7, 2018 - 20:04

OK, here's one example - there are many others:

Image 1:
The paper is about the same width as the window and the right side of the paper is very slightly beyond the window. Measure 2 is highlighted and we've just done cmd-C because we plan on copying its contents. Measure 9, the target measure, is also fully visible on the screen. In fact, all the immediate neighbourhood we're working on is nicely visible and life is good.

Image 2:
We've highlighted measure 9 and we've just done cmd-V to paste the contents of measure 2 into measure 9. Surprisingly, the paper has shifted all the way over to the left, thus hiding the immediate neighbourhood and, in particular, hiding the source measure, measure 2. This is confusing and disruptive to the workflow. Also, UNDO does not reverse the shift - that has to be done manually, which requires that the user first figure out what actually just happened (not always obvious because the user isn't expecting it).

I'm guessing that there are two misbehaviours:

  1. Instead of just tweaking the page over a bit to get measure 9 more into the window (which I think might be MuseScore's good intention), the algorithm decides to move the paper the maximum allowable amount to the left.

  2. Instead of a small cosmetic grey margin around the paper, MuseScore implements a huge empty grey margin that occupies 75% of the window dimension. For this reason, the paper shift is very large, thus hiding most of the page from view.

This is just one example of a failure scenario - and the same issue occurs vertically as well as horizontally. The result of all this is that in the course of normal operation these crazy-making apparently-random shifts occur often and they really disrupt the user experience.

Bottom line - maybe you're right and it's actually a bug rather than a feature request. Either way I hope someone will be able to figure out a fix!

IMAGE #1
Screen Shot 2018-04-05 at 13.17.56.jpg

IMAGE #2
Screen Shot 2018-04-05 at 13.18.17.jpg

Reply

• Apr 7, 2018 - 21:21

Do you have the Palettes and the Inspector in view?
Here's what I get on Windows 10:

Select and copy....

Select-copy.png

After paste...

After_paste.png

For me, the score moves so the right edge of the page is up against the Inspector. (The left edge of the page is under the Palettes.)
It's not as drastic a move as what you show.

Regards.

Reply

• Apr 7, 2018 - 22:30

Hi JM6, thanks for looking at this. I didn't have the inspector open but I've tried it now and for me it behaves the same as it did before. I wonder if it could be Mac vs Windows. Two questions if I may:

  1. What happens if you slide the paper further to the right, so that, say, half of measure 9 is underneath the inspector? And then do the same copy-paste? Where does it move to in that case?

  2. How does the screen look if you drag the paper as far down and to the right as it will possibly go? If I do that, mine looks like this:

Screen Shot 2018-04-07 at 17.24.00.jpg

Reply

• Apr 7, 2018 - 23:29

@polarbreeze...

For my images posted above, I set my MuseScore zoom to 200% because that's what you show in your IMAGE #1 and IMAGE #2.

To answer your 2 questions...

Answer 1.
It makes no difference whether I hide half of measure 9 underneath the Inspector, or even if I enlarge the Inspector by dragging its edge over measure 9. No excessive jump like yours is observed.

Answer 2.
Your image shows that you changed your zoom to 100%.

When I try to drag the score off screen, at 200% zoom, it looks like your image:

Zoom_200.png

When I try to drag the score off screen, at 100% zoom, I get:

Zoom_100.png

Regards.

Reply

• Apr 8, 2018 - 01:36

Jm, thanks for the quick reply!
For #2 I was curious how much of the paper remains in the window when the paper is dragged as far as possible. It seems that on your system and on mine it's the same amount, regardless of zoom setting. And that amount is 1/16 of the window area (1/4 in each direction).

Now back to #1, I've subsequently discovered that the "leaping" behaviour occurs on my system 100% of the time I do this kind of copy-paste, regardless of which score, what zoom, presence/absence of line breaks etc. However, your system doesn't do it. On obvious difference is Mac vs Windows, wonder what else it might be. BTW, what version of MuseScore are you running?

Reply

• Apr 8, 2018 - 04:20

Most of the code did not change for 2.1, nor is it different between Mac and Windows.

However, I did find one relevant change that could be explaining something of what you are seeing. There was a bug fixed (see #117486: wrong scrolling of 2nd and subsequent pages when playing a multi-page score with vertical page layout) where the canvas positioning didn't work correctly if a) you chose "Vertical" scrolling in Edit / Preferences / Canvas, and b) you are on a page other than the first. But it looks the change would also affect page 1. And indeed, I can verify a behavior like that shown in the screenshots, if and only if I set that option.

I don't fully understand what is going on in that bug fix, but suspect it needs to be more conservative in whatever it is doing.

EDIT: seems the issue is triggered only if the destination measure does not completely fit on screen (or only just barely fits) at the moment where you paste. If the measure is fully on screen, no jump happens. If the measure is not, the canvas moves to put it on screen - as it absolutely should - but is overly aggresive and puts it further to the left than necessary. It's supposed to be positioning it to the right edge of the screen but this doesn't seem to be working.

Reply

• Apr 6, 2018 - 22:11

Aha!!
This could be the issue here. There seems to be a canvas layout rule that allows the paper to move (or to be moved) far off the screen, until 75% of the window is empty (ie 75% in each direction, see image). It serves no obvious purpose for this value to be so huge. If the limit were, say, 5%, that would make much more sense. Or even 0% - who needs to see the grey background? I have a feeling that simply changing a couple of constant values somewhere might go a long way towards solving this problem. In fact, maybe this will turn out to be the primary cause. I wonder if Mac and PC behave the same way in this respect?

Screen Shot 2018-04-06 at 16.54.24.jpg

Reply

• Apr 8, 2018 - 08:48

Aside (to Polarbreeze):
Keep in mind that you can upload videos to cloud storage and provide links (Dropbox.com for example), or, there are open source tools to convert your videos to .gif files (VirtualDub for example) – MuseScore's forum allows an uploading of .gif files, and they're useful for demonstrations of bugs or handbook guides.

Reply

Do you still have an unanswered question? Please log in first to post your question.