Allow long note groups to scroll or pan in "Create Time Signature" dialog

Just for comparative purposes, here's how much you would have to stretch that dialog without scroll bars:

Good idea. I'd like to second the request.

well, this is certainly not a restriction of Win7, but of your screen's size :-)

Proposed PR:
https://github.com/musescore/MuseScore/pull/2288

I copied the part of code from scoreview.cpp responsible for panning of the score.
This solution can still be improved, for example adding a "white" margin around the system inside the example view, and/or enabling navigation inside the example dialog via keyborad (for accessibility).
At the moment I am not sure that the exampleview can be used with the keyboard (to change the beam properties), so maybe the second point here above can be postponed to when this dialog will be keyboard-friendly.

This one has been vexing me a bunch lately. Any reason not to merge the fix?

Came up again, requested by duck57 and JGitar at https://musescore.org/en/user/101731/blog/2016/05/01/musescore-3.0-unde…. The PR is still there, still ready to merge...

I updated the PR for v3.0-dev.
I don't know if it works also for 2.0.4, maybe the "10" at line https://github.com/musescore/MuseScore/pull/2288/files#diff-25c41ba1ac4… must be reverted to "7" for 2.0.4.

Came up again on #125686: Note groups are truncated in the Time Signatures dialog

Came up again: https://musescore.org/en/user/101731/blog/2016/05/01/musescore-3.0-unde… The PR looks to be still mergeable.

This is one of the issues I'd really like to see fixed in 2.1. Are there any remaining problems with Antonio's PR (https://github.com/musescore/MuseScore/pull/2288)?

I think I filed this?: #47221: Note Groups cut off in Time Signature section of Master Palette

Yes, looks like one is a duplicate of the other

No one ever answered Isaac on #12. I noticed it is not fixed in 2.1-dev.

That is why the issue is still open

Fixed in branch master, commit 25a4bf58c7

Fix #84416 : Allow long note groups to scroll or pan in Create Time Signature dialog

maybe we can get it into 2.1 too?

Fixed in branch 2.1, commit 04b169d7a8

Fix #84416 : Allow long note groups to scroll or pan in Create Time Signature dialog

Fixed in branch 2.1, commit ba40e884f3

Merge pull request #3014 from AntonioBL/2.1

fix #84416 [2.1 branch] Allow long note groups to scroll or pan in "Create Time Signature" dialog

https://github.com/musescore/MuseScore/pull/3014 was merged into the 2.1 branch, and it's listed in the draft of the release notes at https://musescore.org/en/developers-handbook/release-notes/release-note…, but with the latest 2.1 nightly b4d3de2 I don't see any sign of it—the same problem as before still exists in the UI.

In fact, it doesn't seem fixed in latest master 99c15fd, either.

Well, it is popssible to scroll/pan those long note groups, just grab it with the mouse and move sideways, this is not possible in 2.0.3
There is not scroll bar though, but I don't think that was part of th fix.

Attached an animated gif showing the behavior.
It scrolls like the main score (i.e. click and drag), but no scroll bar is present.

Hmm, I see. If you don't mind my saying so, I don't think anybody will discover this. Why does the mouse wheel / trackpad swipe / etc. not work here like it does in the main score?

Well, because a wheelevent has not been implemented (yet) for the ExampleView.
I briefly looked at the relevant function in ScoreView, and I think writing a similar one for this ExampleView should be straightforward.
However, I see that a swipe event can have both x and y movements. How should the scrolling behave in this case? In particular for trackpad swipe (e.g. "two-fingers" swipe):
- should a vertical swipe be translated to a horizontal scroll (as in ScoreView when holding shift)?
- or should only a horizontal swipe give a horizontal scroll?
- How "diagonal" swipes should be treated?

I think for wheel scroll it is easier: a vertical movement (this is apparently the output of a wheel scroll) should become a horizontal movement.

"a swipe event can have both x and y movements. How should the scrolling behave in this case?"

I would say to ignore the y component completely. Use the x component only for the scrolling. So a diagonal swipe would just ignore the y component.

Wheel scroll would be great.

There is also the question of whether there should be a small scroll bar...I don't know the answer.

I agree with Eric: vertical can be safely ignored. As to the question of the scroll bar, I would like it a lot, but it's not critical.

I vote for a scroll bar.

PR for wheel scroll:
https://github.com/musescore/MuseScore/pull/3024
I have a doubt about the direction of scrolling when using (vertical-movement-only) mouse wheel (which direction should the preview go?)

Tests are welcome, in particular under Mac (about horizontal/vertical/diagonal swipe).

Edit: About the scroll-bar, I couldn't find how to easily make one appear, since I think it is actually the score being repainted at a different position inside the window instead of a true scroll. But I can be wrong :-)

"I have a doubt about the direction of scrolling when using (vertical-movement-only) mouse wheel (which direction should the preview go?)"

I would say mouse wheel up should scroll left towards start of system, and mouse wheel down should scroll right towards end of system.

scroll wheel down -> move right, just like shift scroll wheel down in score view

What Jojo said, except it needs to have the same setting as the score does. I use ctrl-wheel to scroll the score left and right all the time. It would be disconcerting to not be able to press the ctrl-wheel to scroll left and right here. I realize that up and down scroll is never needed in this window, but you could make it work the same with or without ctrl pressed.

Ok. In the PR is already implemented like that (it is a clone of the ScoreView).
It does not need another key to be pressed (contrary to ScoreView), so it works also when Ctrl, or Shift, or Alt are pressed (I tested under Windows 10).
I would prefer someone testing the swipe under Mac. If needed, I think I can provide a link to a Mac build (Sierra, but probably working also under Yosemithe) of master branch later this afternoon for testing purposes.

EDIT:
And here is a link to a personal build of the Mac version (master branch)
https://drive.google.com/file/d/0BxjayMZiuupOaWJ1cDBURG01WEk/view?usp=s…

Works exactly as I would expect on my El Capitan MacBook!

Thank you for the tests.
I also made a PR for 2.1:
https://github.com/musescore/MuseScore/pull/3025

And both PRs are now merged.

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