Allow dragging the score without losing selection
Sometimes I want to select a range of notes/bars that are distant, so I would like to select the first, then navigate to the other one by clicking and dragging to then select it. Unfortunately, when I click and drag to move the score around, the selection is lost.
I know it's necessary to unselect everything when you click an empty place, but I think it should cancel selection only when you simply press and release the mouse button and not when you click and drag to move the score around.
Comments
Dragging isn't the way to select multiple measures. Instead, click one measure, shift+click the next. And you don't need to drag to get to the next - just use the mouse wheel or other navigation methods. Or. click one measure and use Shift plus arrow keys to extend the selection.
In reply to Dragging isn't the way to by Marc Sabatella
Yes. The methods that you described are the ones I use for now. But this is not really what I meant, I'll try to explain better now:
When I select measures, most of the times, I use the method that you described: Click one measure, then shift+click the next. The thing is that sometimes the next is very far away. So I click, drag the score until I reach the desired place and shift+click the other measure. But that does not work because the selection is lost when I drag. I can use the mouse wheel or use other navigation methods (like using the navigator, that allows me to drag the score around without losing selection), but I think this method that I described is nicer (or at least a good alternative), and I don't believe there is any scenario where losing the selection when dragging the score around is desirable.
In reply to Yes. The methods that you by eduardomezencio
You can use the mouse scroll wheel to navigate to the end position: {scroll up/down} moves the score up/down and {shift-scroll up/down} moves it left/right without losing the initial selection; once you find your end measure {shift-click} will extend the selection.
Also you can achieve it using the navigator window (F12 key) and drag the sliding window in there.
In reply to You can use the mouse scroll by .m.i.r.o.
Yes, as I said, I use both methods you described. I'm just suggesting a nice new one.
In reply to Yes, as I said, I use both by eduardomezencio
Perhaps my viewpoint is OS-influenced (we use Win7), but I don't find the idea particularly intuitive (or necessary) from a user standpoint. Text selection (highlighting) in most Windows-compatible programs is click-hold-swipe (or a keyboard/mouse combo variation), and releasing the mouse button defines the end of the selection. Any new click made before executing some other action upon the highlighted text cancels the selection and creates a new selection start point. I think most people running any similar system are quite used to that.
Some programs which involve multi-screen documents (notably photo editors, certain PDF viewers/editors and MuseScore) enable click-and-grab moving of the entire screenful, and for these, click-hold-swipe highlighting obviously can not work (unless the 'hand grabber' can be toggled from a toolbar or dropdown).
But MuseScore provides many easier ways to select material in a score. A single click can pinpoint one note or even part of it (head, stem, flag, dot) precisely. CTL+click adds things to the selection; and click + --> + END (or click+SHIFT+CTL+END) selects to the end of the line (or the entire score) quickly and easily. When selecting just a few measures click + --> (or <--) selects each note or element in sequence; click+SHIFT+CTL+ --> (or <--) selects a whole measure at a time. If one selects certain measures in one instrument, and then wishes to include one or more additional instruments or voices, CTL+down-arrow (or up-arrow) adds the staff below (or above) to the selection.
Finally, there is an way to do pretty much what you want, although you must use the mouse-wheel to scroll the score vertically or horizontally (unshift or shift while rolling the wheel) instead of the click-and-grab function. If you select a section of the score using any of the above methods, and then scroll the score using the mousewheel, pressing SHIFT again (and holding it) while clicking on the new measure you want to select will extend your original selection to the new point on which you clicked. Note that if you don't hold down shift, though, the original selection will be cancelled.
With all those easier ways to select material in a score, I really don't see the need for an additional method, especially one which could easily conflict with other needed functions.
It is possible to navigate through the score while keeping the current selection using the Navigator window.
+1 for this request:
However, I myself fall for this from time to time, when I want to select just a little more than is shown in the main score window. Being able to drag inside the main score window would mean less effort, than having to move the mouse to the Navigator first and try to move by an exact amount there... So I think it would come very handy, although of course, this has only low priority. Also I don't see any downsides, this might have.
+1 from me. In terms of sheer reasonableness, I see it as comparable to https://github.com/musescore/MuseScore/pull/2243.
I have created PR 2481 for this feature.
My approach cancels the selection, if the mouse was not moved and the button was released after no more than 450ms. If the mouse was moved, or the button was pressed for a longer time, the selection is kept.
In reply to I have created PR 2481 for by heuchi
Thanks for the PR I will try it out but I still don't see why using click and drag to move the score and not Scroll and Shift+Scroll if you don't want the selection to be lost.
In reply to Thanks for the PR I will try by [DELETED] 5
Not everyone has a mouse wheel?
In reply to Not everyone has a mouse by Jojo-Schmitz
Strong point.
In reply to Not everyone has a mouse by Jojo-Schmitz
I didn't know one could buy a wheel-less mouse anymore! Even our 'Dragon' (the 16 year-old desktop in the back office) has a wheeled mouse, and that's so old we have to clean the lint and crud off the rollers every year or so. ;o)
In reply to Not everyone has a mouse by Jojo-Schmitz
Also, touchpads don't usually have wheels, but they generally have equivalent gestures (eg, two finger swipe, or a "scroll zone", etc.
In reply to Also, touchpads don't usually by Marc Sabatella
Yes. 99.9% of our Musescore work is done on laptops; and although I believe most people eventually add a wireless mouse for convenience at home, I don't always bring the mouse when I'm travelling so the touchpad functions come into play.
Long plane rides are good oppotunities to get work done (hint: bring a clothespin to clip the MS you're transcribing to the seatback pocket in front of you!), but there's not much space to use a mouse on those tray-tables in tourist class. A quick bit of experimentation indicates that scrolling functions work the same way as with a mouse while using a touchpad, even if the technique is a bit 'touchy'. ;o)
In reply to Not everyone has a mouse by Jojo-Schmitz
A big score with many pages. Mousewheel does not help in normal view coming from page 1 to 4.
Using continuous view, you are not able to go to a part outside the screen.
You can use the navigator. But if you have a small screen like laptop or netbook, someone shut down the navigator keeping the overview. It is annoying.
I showed a 75 years old man to make oldeyefriendly notes(very big) with Musescore on his laptop. He is really pissed off of this strange behaviour moving the score.
The main problem of the UI is, it does not accord to the standards of using software( in the windows world. I am reasoning whether the UI follow any standard or is only chaotic. Being consistent is something different.)
In reply to A big score with many pages. by hasenfuss
Shift+scroll works sideways
In reply to A big score with many pages. by hasenfuss
To be clear: the mousewheel *does* allow horizontal scrolling, including scrolling from 1 to 4. Simply hold Shift while scrolling. You should never need drag to navigate; it's more suited for fine positioning.
In reply to Thanks for the PR I will try by [DELETED] 5
I just have greater control of the direction and speed of movement when dragging.
In reply to Thanks for the PR I will try by [DELETED] 5
Well, for me click and drag feels easier and also noticeably quicker, if I need to scroll diagonally. When using click and drag, I can do it in one go, while I have to do it in two separate steps using Scroll and Shift+Scroll.
In reply to Well, for me click and drag by heuchi
I doubt seriously that click-and-drag is quicker than zooming the score (using mouse-wheel + CTL) to a size that puts everything you want to see on the same screen. You can then click on a start point, SHIFT-click to define an end point, and your selection is made. No muss, no fuss, no bother.
I object to the mechanisms you propose in your PR rather strongly, actually. If I have to think about how long to hold down the mouse-button everytime I click on something--or need to be specially careful not to move it within x microsecs--it will seriously slow down my work processes. I know of no other program of any sort wherein a mouse-click is timed; a click is a click, period--and moving the mouse during the clicking process is always ignored, as some slight movement is almost inevitable. Human hands are just not precise enough to avoid enough displacement to be detectable by a computer capable of measuring movement in nanometres.
If this PR is merged at all, I would strongly urge that it be made an option, not the default behaviour.
In reply to I doubt seriously that by Recorder485
To me the whole thing just seems quite unnecessary. As stated, there are easily available tools already. This would not be high on my list of preferred places to concentrate. :)
In reply to I doubt seriously that by Recorder485
I also am very uncomfortable with making anything depend on the timing of the clicks.
Dragging is bound to be inefficient for anything but very small motions - surely it's not a good way to move several wpages for instance. So one way or another it seems one needs to make piece with the scroll wheel. If your particular mouse or touchpad settings makes this motion uncomfortable, you might consider whether a different mouse or different touchpad settings would make things easier. Personally, I can't imagine any thingout where I'd choose dragging over two-finger swipe.
In reply to I also am very uncomfortable by Marc Sabatella
I understand if you and other people are concerned about making something depend on the timing of clicks. But there are also other ways to implement this. Musescore has already a way to detect if you really wanted to drag something or if you inly moved a little, maybe by accident, because that's what it does when you try to move a text with the mouse. If you drag just a little, it does not move the object. It only starts moving the object when you drag a significant distance.
The same method could be reused to detect if you wanted to deselect when clicking or not. Dragging behavior would continue the same, but if you dragged an insignificant distance, the selection would be cleared. If you dragged a significant distance, nothing would be done to the current selection.
This way you would not need to worry about using timing of clicks and would be able to reuse a user interface concept that is already used in the program.
In reply to I doubt seriously that by Recorder485
@Recorder485:
Your image has a width of 14114, so you seem to have an exceptionally large screen. Well, I have not and I just tried it. It's a lot slower, because once I zoom out to the needed degree, it's a lot harder to hit the right point in a measure, and since everything is very small, it's not even easy to quickly see what has been selected. So, doubt it or not, for me, dragging is a lot faster, as I already said, and I cannot help wondering, why you would doubt it at all.
I'm having serious problems understanding your objections:
Generally speeking: I really don't understand why anybody should insist on keeping the possibility to clear the selection by dragging around the score. I don't see any connection in these two actions. There is an easy way to deselect all: press Escape. Always works, no matter how shaky your hands may be.
I really don't understand this strong objection to something, that seems to not even make any difference to those objecting to it. Are you saying you need to be able to deselect all by clicking on an empty space for a long time, or by dragging around the score using the mouse, an option you seem to not even use anyway?
So simply put: Besides from some theoretical "I doubt, that ..." or "I don't like if ...": What is the disadvantage you're afraid of?
In reply to @Recorder485: Your image has by heuchi
I don't think I have an exceptionally large screen; this is an ordinary HP ProBook with a 29x16.5cm screen, which corresponds to today's standard 'wide-screen' 16:9 aspect ratio. I don't, however, have control over the size of the images generated by the image-capture function in MuseScore unless I want to save the image, then open it in a photo-editor, re-size it, and re-save it under a new name before uploading. I apologise if my laziness in not doing that caused a problem for you in seeing the image.
The problem with the mechanism in your PR is that it would create behaviour which runs counter to that which most people have learned to expect when using a mouse. That can lead to problems and lost data, because when you expect a selection to be cleared and it's not, almost any subsequent action will cause bad things to happen. I vividly remember a cheap netbook I once owned which had a hyper-sentsitive, flaky touch-pad, and would select things without my wanting them selected. ANYthing I typed after that would, obviously, erase and replace the entire selection, and while CTL+Z sometimes got it back, it didn't always. I finally fixed that problem--with a sledgehammer and a credit card (to buy a new laptop.) ;o)
If you use both hands to do things, instead of relying completely on the mouse, I think you will soon find that the combination of keyboard shortcuts and mouse-wheel makes it possible to get around in a score much more quickly than by repeatedly clicking and dragging, clicking and dragging, especially when, as Marc noted, you want to move several screen-widths away from where you started.
In reply to I don't think I have an by Recorder485
MuseScore already has behavior which runs counter to that which most people have learned to expect when using a mouse—when you click on an empty spot on the page and drag, the page moves!
You would click and drag and expect the selection to be cleared, and I would expect that, too—because I would expect it to be replaced by a new selection consisting of everything in the rectangle between the two points where I started and ended the drag across the unmoving page (which you have to hold down [Shift] to achieve in MuseScore). But MuseScore does behave in this contrary fashion where dragging moves the page, so I would then expect moving the page to have nothing to do with selection at all. Which is what is proposed.
But it has been made quite clear that the future behavior of clicking without dragging is secure no matter what—the selection will continue to be cleared if you click on the page but don't drag.
In reply to It would create behaviour by Isaac Weiss
That's common, expected behaviour with image programs, such as photo editors, maps, and PDF viewers. MuseScore is at least partially image-based, so it should not be unexpected that grab-and-drag works. (Text programs do not usually offer grab-and-drag because text files rarely need to exceed screen width, so only vertical scrolling is needed. In such programs, using the mouse-wheel or the up/down arrows is faster and easier than grab-and-drag except for very small movements.)
Don't get me wrong: Grab-and-drag is convenient in MuseScore on occasion--again, for very small movements--but I simply do not believe it's necessary or desireable to make a radical change to the response to mouse commands in order to enable dragging a score while selecting part of it.
In reply to MuseScore already has by Recorder485
Me neither. I just think it would be better if moving the page had nothing to do with selections at all.
In reply to @Recorder485: Your image has by heuchi
I don't understand the reference to zoom; what does that have to do with scrolling> Seems zooming is needed more in conjunction with *dragging*; I don't see why I'd ever zoom in or out normally just to navigate.
Anyhow, while I don't like making behaviro dependent on timing, I'm not necessarily opposed to just 8always* making drag keep the selection if possible.
In reply to I don't understand the by Marc Sabatella
So, please, give me your opinion on this https://musescore.org/en/node/102796#comment-463591
It's a solution that I'm proposing that is not timing dependant
In reply to I don't understand the by Marc Sabatella
Marc, mouse-wheel zooming is FAST. One flick of the finger on that wheel brings a score from 100% down to 40% in a split second. So, if you zoom-down a lengthy score to a small size, you can then scroll laterally through the pages MUCH more quickly. When you get to where you want to be, you quickly zoom back up to a size you can work with. I routinely use all three mouse-wheel options to get around any score quickly and without trouble.
In reply to Well, for me click and drag by heuchi
Seems like the naysayers haven't tried this option out. I compiled a local version to test it and fully support this change. Can someone describe a *concrete* example of where this simple mod will break something?
I'm mainly a mouse user (yes, with scroll wheel), but would love to also be able to move the score with mouse-drag. Photoshop, a heavily used program by me, has CTRL for left/right instead of SHIFT, which always causes zoom and scroll direction confusion when switching to other programs.
In reply to Seems like the naysayers by schepers
Can't you change the shortcut in Photoshop so it matches the other programs you run? One of the things I really appreciate about MuseScore is how easy it is to modify keyboard shortcuts to match my needs or idiosyncracies. (I know Adobe is NOT known for making that sort of thing easy, but if you are computer-savvy enough to compile your own version of MuseScore, you stand a better chance than I of finding the appropriate lines of code.;o)
As to the PR in question, I have explained my reasons for objecting to it in some detail in other posts so I won't repeat myself except to say I think it is unnecessary and counter-intuitive. There are many more important fixes and features to work out, IMO.
In reply to Well, for me click and drag by heuchi
The problem we're discussing actually arises from the fact, that MuseScore
Why would you have two different ways of dragging the score, one (using the wheel) keeping the selection, and another clearing it. It just doesn't make sense. It's not only about "selecting" using a mouse-drag in between. It's also about dragging the score after a selection has been made, before all planned action using this selection has been completed.
You brought up the point, that if someones expects the selection to be cleared when it actually is not, bad things will happen.
So do people rely on the fact, that dragging the score with the mouse clears the selection first?
I don't think so and I'd strongly prefer a consistent behaviour like this:
You want to clear the selection:
You want to drag the score:
Why should we mix it up?
I don't insist on any of the detail of the current PR. I found out I like the timing feature I put in, but it seems to be confusing, so we could drop it.
Also, there could be used a threshold for a minimal distance the mouse needs to travel until we consider it dragging. So there would be no "no movement at all" problem, when clicking in an empty space to deselect all.
In reply to The problem we're discussing by heuchi
Scrolling and dragging are not the same thing. If they were, the problem complained of wouldn't be an issue in the first place.
My point is that MuseScore already offers three very rapid, distinct methods for selecting material, and none of them requires any change to typical mouse-command behaviour.
Selecting material is usually done for one of the following reasons:
1. To transpose it to another key
2. To transpose it to another octave
3. To change its visibility, colour, or head-type
4. To assign a specific articulation to the notes within it
5. To copy it to the clipboard
6. To delete it
For reasons 1 and 3, the usual selection will be the entire score or part, so CTL+A or Select+CTL+End will get the job done in two or three keystrokes.
For the other reasons, Select + --> (or END, repeat as needed) will quickly highlight the measures wanted, and the desired operation can be performed upon them.
Instead, we are faced with a proposal which would change the expected behaviour dependent upon the length of time one holds down the mouse button (have you never clicked on something thoughtfully that you weren't entirely sure of, and let your finger linger on the button before releasing it?) or upon whether or not the mouse was displaced while the button was depressed.
As a professional user, I rarely if ever use the mouse for input. Keyboard or Midi input is much faster and easier. OTOH, I use it frequently while editing, proofreading, or doing layout. For that sort of work, it is invaluable, but when keyboard shortcuts are available, they are still faster and more precise.
The current system works extremely well. In the words of the anonymous sage, 'If it ain't broke, don't fix it.' All programmers know that everytime a new line of code is added to a program, a new potential for a bug is introduced. Why risk that for something that isn't really needed?
Just to complement this discussion, I remember that my suggestion coincides with the way that Sibelius work, and it worked really well. My friends that use it find it very important feature.
The thing is: I don't know how it is implemented in Sibelius, if it's time based, or if it's related to how much you drag, to detect if the selection should be cleared or not. But one thing I remember: it works and works well.
So if anyone here have Sibelius, could you test and try to find out what is the method it uses? Please don't get me wrong, I'm not saying "do like them, and that's it". I think it's a nice piece of information to complement this discussion, and it's also a nice way of testing this feature at work to see if it's nice or not.
I just finished using musescore to transcribe the entire Mozart 40th symphony, I was using it for several hours a day for like a week, and I felt the need to have this feature soo many times to make my work easier. That's why I started this discussion.
I've just tried some different settings and would like to propose the following:
I'm going to update the PR tomorrow.
I have updated the PR. No timing any more.
In reply to I have updated the PR. No by heuchi
I tried it. I like it. Any other feedback?
In reply to I tried it. I like it. Any by [DELETED] 5
+1. Previous behavoir drove me mad on more than one occasion
In reply to I tried it. I like it. Any by [DELETED] 5
I'm less worried now that the timer has been removed.
In reply to I tried it. I like it. Any by [DELETED] 5
It took me a while to test because I had never figured out how to pull a pull request from github to my local repo using git...
I think it's working really great!
In reply to It took me a while to test by eduardomezencio
This is now merged in master and 2.0.3. Thank you heuchi!
In reply to This is now merged in master by [DELETED] 5
It's the little things like this that go a long way to making MuseScore more perfect. My thanks to all involved.
[ironic]And they so comfortable.[/ironic]
Not everything what is possible, is comfortable.
What about scrollbars and using page-up and down-keys?
In reply to [ironic]And they so by hasenfuss
page-up/down do work, vertical scroll bar is part of the Navigator, but just eat precious screen space otherwise