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

• Oct 21, 2015 - 23:23
Reported version
2.1
Type
Graphical (UI)
Severity
S5 - Suggestion
Status
closed
Project

In "Create Time Signature", the 8ths/16ths/32nds can extend past the edge of the dialog, with no visible way to access and edit the hidden parts. Resizing the dialog window might not be sufficient to reveal all the notes.

(Originally posted in the feature request forum: https://musescore.org/en/node/83681 )


Comments

Resizing the dialog window might not be sufficient...

On my Win7 box, the dialog can't be made wider than the screen; that wasn't enough to reach everything in a 15/8 time signature.

Status (old) active patch (code needs review)

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.

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

This kind of setup would make a nice holiday present... :-)
multi-monitors.jpg

Status (old) needs info fixed

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.

video_time_sig.gif

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.

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.

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…