add rest on right click in note input mode

[MarcSabatella]

See https://musescore.org/en/node/269001 for discussion. There have been many complaints over the years about usability issues enterings rests using the mouse, most focusing on the toolbar appearance and behavior. And sure, it could be worth revisiting that some day. But it occurs to me there is a much simpler way to improve efficiency: allow right click to enter a rest of the current duration, no need to first click the rest icon. True, it's not the most discoverable interface, but my goal here is improving efficiency, for those users who for whatever reason want to use the mouse rather than keyboard.

It's just a few lines of code to implement. Works for the equivalent right-click gesture (two-finger tap) on my Windows touchpad system, I would hope same would be true for Mac although obviously that would need to be tested. This PR is for 2.2; the same code works for master but would need to go into events.cpp instead. For master, right-click currently activates the context menu in note input mode, although it is not clear that this is intentional, as right-click does not do this in 2.x and there doesn't seem to be any point to it in master.

[19joho66]

There has been a proposal on the implementation of a right click menue about two years ago. (see https://musescore.org/en/node/99536 and #2401)
The useage of the right mouse button in the Note Entry Mode is momentarily not intuitive. I expect some kind of context menu when I use the right button. The proposal gives you all possibilities of the note entry toolbar on the spot and lets you switch betwen note and break entry. The resonance was quite positive but it was never purused further. Maybe it would be worthwhile to have another look at it.

[MarcSabatella]

Thanks, that helps me understand at least a possible reason for right-click to be active in note input mode - to allow easier duration changes by mouse. Although it doesn't actually work this way now in master - it pops up the same context menu you'd get while in normal mode, and it also enters a note simultaneously, which is just plain bad. And in any case, I suspect there are better ways of allowing for easier duration change by mouse, like the long-tap suggestion in the aforementioned thread. I also wonder which actually saves more effort in the long run - allowing less mouse movement for duration change, or allowing easier rest input? Could be worth some studies.

I would also note the ideas are not totally incompatible. A short right click could enter the rest, longer (either right or left) bring up the context menu. Or "middle" button for context menu. Or right click could bring up context menu but with "add rest" as an item, which is still more efficient than currently.

[19joho66]

Well, I don't know if the short-click/long-click concept is a very good idea. Some certain standarts have been established for user interaction in modern programs. I've never seen any program which uses the concept of an long right click, so I would never try by intuition. (And the very basic use cases should not require reading the manual)
In modern programs the right click almost always produces an context menue for the active mode or object. (e.g. in a paint program right clicking on a rectangle gives you options for manipulation this object). This is what the user expects, so if I right click in note entry mode, I expect a menue which gives me options for the note entry like durations punctuations etc.
A modern program should concider the expectiations of the user in order to get a good acceptance. The first time I used musescore, I was quite irritated when I used the right click in note entry mode and no context menue popped up, but a note was entered somewhere. Thats why I implemented the right click menue in the first place.
I think the long click concept is only used for touch screens to implement/simulate a right click

[MarcSabatella]

I would agree long right-click is not relevant, long left-click is better. And true, it's more a touch thing than a desktop thing, but modern users are well acquainted with it, so I don't see that as a deal-breaker. As observed elsewhere, if you are really concerned with efficiency, you won't be messing with clicks at all - right or left, long or short - but will instead ditch the mouse for the keyboard. So really it's more about how to make mouse entry slightly less inefficient.

It's true right click is usually a context menu, and MuseScore uses this to good effect in many palces. but it's normally about changing the selecting element, not just about moving the toolbar closer to the mouse. Very few programs I can think of work that way. Eg, word processors, right clicking while typing text seldom move the text formatting toolbar down to your mouse position. So I don't see that as being an expectation. The right click menu is normally more about providing additional commands than moving the toolbar, and in MuseScore, there really aren't many additional commands available in note input mode. So it feels a bit unnatural / inconsistent to me. But if others find it useful, that's fine - just maybe if it could combine the best of both suggestions, then it would be even better.

[mirabilos]

There’s always the option of having a right-click menu that preselects “enter rest”, so if you do only a short right-click, a rest is entered, and if you want to select a different item from the menu, you have to hold down the mouse button while moving the cursor to it.

This is used for example in the classic Unix xterm (where you have to hold both Ctrl and the mouse button though); it’s not considered the best UI any more nowadays, but at least possibly less confusing and door-closing than to hardwire right-click to “enter rest”.

[kuwitt]

For me mirabilos suggestion sounds more clear than a solution about a long left click.

Another inspiration: With the graphic application Gimp it's possible to change the function while holding "ctrl" and left click (for example it changes the pencil to the pipette), the context menu is still available via right click (not sure, how it works with Mac).
For MuseScore it could mean, while "ctrl" is pressed insert a rest else insert a note (and a faster note input method instead of turning on/of the rest symbol each time).

[mirabilos]

A long left click is usually the same as a right click in “mobile”. I’ve observed this in Ewe (a Java framework) on PocketPC (WinCE) but also desktop; on other PocketPC applications, and Android, so far.

[anatoly-os]

If we don't use ctrl/cmd modifier yet, it is good point to start, I agree with @kuwitt. It is good UX without side-effects.

[MarcSabatella]

The issue with Ctrl is, as soon as you require use of the keyboard, you might as well just use the regular shortcut 0. I mean, who wants to press Ctrl and have to click simulaltaneously if they can just press 0 instead? The whole point is to improve the workflow when not using the keyboard.

[kuwitt]

I think, we agree that the "0" for a rest doesn't make any sense with mouse input. The user don't get any visible response, when he pressed the key if something changed, you'll furthermore see a blue note. And there's consense to turn on and off again the rest symbol each time doesn't mean a good workflow (resp. this could be surley improved).

And indeed it wouldn't make any sense to use instead of "0" the "ctrl" in the same way (except that the "0" by using a touchpad isn't in a very comfortable position for a righty like me( you've to cross the hands)).

But the behaviour ctrl+mouseclick I mean't in my comment above in adaption to some other applications would work a little bit different: If you press (hold) "ctrl", the mouse cursor changes from a blue note to a blue rest (so that's obviously for the user, what will happen and will see, what he expect), pressing the left mouse will enter the rest. As mentioned it's only an alternative way. And indeed, it would mean to use the keyboard, but it's a common way in applications is more in sense of "What you see is what you get".

I don't know many desktop applications with a long left click, but I could live with that solution without any problems (maybe MuseScore will there be a pioneer on desktop PCs and other will follow ;).

Btw. the notation program Primus from columbussoft is using left click for notes/right click for rests.

[MarcSabatella]

I never said 0 doesn't make sense. I said that Ctrl+click doesn't make sense, since it is harder than simply pressing 0. If a user is going to use the keyboard, why introduce a new command that is harder than what we already have? I would rather help the case where the user doesn't touch the mouse.

It's not true that 0 gives no visible feedback - you get a rest added to your score, that's your visible feedback right there :-). But yeah, Ctrl+click does have the advantage of allowing the mouse cursor ("shadow note") to change upon pressing Ctrl. Still, I'd rather have the rest added than watch the cursor change but still need to take an extra step to get the rest added.

[kuwitt]

I stand by it: "0" in context with the mouse input doesn't make any sense for me. I dont't know any application, where "0" is used in context with mouse input. But I know applications where "ctrl" is used in context with mouse input (graphic applications).
Outside the note input mode we're using "ctrl"+click or "shift"+click for a range selection. But "0" isn't a consistent behaviour of mouse input in my oppinion. So if a keyboard key is necessary for mouse input, I would prefer a "while holding ctrl the mouse cursor change to a rest symbol so that's clear (shadow note/rest), what I expect by left click" (in the same way, when I activate the rest symbol in the toolbar - the mouse symbol switches fom a blue note to a blue rest of the selected duration)
Yes, the best way would be and it would be more consistent, don't needing the keyboard for the mouse input and speed it up without taking the long journey of activating and deactivating again the rest symbol inside the toolbar.
The concept for right click to insert a rest isn't new in music notation applications. I mentioned Primus, which I never used (because there doesn't exist a Linux version). Another application, I've used before MuseScore was NoteEdit (and NtEd before and for a short time the further development named Canorus). Definitely NoteEdit (I don't remember, but I think the other too) were using the concept with right click for rest input. So it wouldn't be unusual for the mouse input.

So for me the question would be:

It's possible both - a right click for rest input and an implementation of the feature from 19joho66?

[MarcSabatella]

I think you are misunderstanding. I am not suggesting while clicking the mouse, I am talking about pressing 0 instead of clicking the mouse. Lots of people use rheouse and keyboard together; it's perfectly common and normal. Eg, click a marking with mouse, press Del to delete. So if the keyboard is within reach anyhow, who in their right would choose to do Ctrl+click instead of simply pressing 0? That's why to me Ctrl+click is not really worth implementing to me - it's not an improvement over what we already have. I am I interested in implementing an easier workflow, not a harder one. Hence, right click interests me, Ctrl+click is better reserved for something else.

Anyhow, ideally to me right click would.dp it's job immediately, no need to pop up a context menu that requires yet another click. If it's possible to make right click pop up the context menu with "Enter Rest" already highlighted so all you need to do is release, I guess that could be OK. But such a change seems out of the question for 2.2 at this point I would think. Probably mine is as well.

[19joho66]

I think one should concider the whole workflow when using the mouse. What I don't like when I use the mouse in musescore are the long distances. Always when I have to change something like the note lenght I need to go all the way up to the toolbar and then back to the input position. This totally breaks the workflow. Another thing I don't like is that I have to go to the the toolbar to enable or disable the input mode. Often there is the situation where I need to correct the last input (e.g. move a note up or down, change the length of the note etc.) In this case I would like to right click, disable the input mode, do the changes, right click again and then change back to input mode. All of this without leaving the input position too far. I don't think it does matter if I have to do two clicks as long as I can stay on the spot. It takes much longer to go to the toolbar and back than to do a right and a left click.
With my proposal I was targeting exacly this - having a smooth workflow with the mouse.

[MarcSabatella]

I would agree it is important to improve the overall workflow. But what I'm really talking about is something a little different. We already have a great solution for those whose primary concern is overall efficiency - put the mouse away and use the keyboard. Guaranteed huge improvement in efficiency right there, no code changes required at all.

So while efficiency is important, that's not the only concern here. The point of my change isn't so much about improving overall efficiency as it is about improving other aspects of the experience when using the mouse. For instance, while having to move the mouse to the toolbar to change durations might not be efficient, it does feel natural - completely in line with expectations based on how most other toolbar-based programs work. Whereas the issue with rests isn't just about efficiency but about the lack of consistency - how the process feels disconnected from how note entry works. Even relatively experienced users who would never question the need to use the toolbar for durations don't like how it works for rests.

That's why we often get requests to have a whole separate rest toolbar like the note toolbar, instead of requiring a combination of using one icon to set duration and another to enable "rest mode". Such a change has virtually no effect on efficiency - it would still be infinitely slower than keyboard entry. But would go a long ways toward addressing some other equally valid usability concerns with the current system. Frankly, rests are really the only commonly expressed concern about the note entry we get (others about editing, but that's totally separate).

To me, then, the driving force here isn't efficiency alone but the bigger picture that also includes naturalness, and discoverability as well. Not saying the context menu idea doesn't do decently on those fronts, but that's the more important question to be looking at here.

[anatoly-os]

The idea with holding Ctrl is better then pressing 0 due to the positions of the buttons. Ctrl is close to the free (left) hand, so holding it to enter rest is much easier than pressing zero, imho.

[MarcSabatella]

But right click is easier still, no? Which is one reason I coded it that way. Another is that Ctrl+click is reserved for another function in master.

[mirabilos]

True, but right-click is still easier, and with what I suggested (right-click that is immediately released inserts a rest, right-click that is held opens a context menu once we have one; until then, the only menu entry is “enter a rest”) even future-compatible.

Again, do note that, on tablet devices, it’s a convention that a long press is a right-click. Perhaps that one should open the menu.

[19joho66]

You may be right that if you are concerned with efficency you use the keyboard. (And if you are really serious about efficiency and want excellent engraving too, you use lilypond)
But that is not the point here. This concerns the efficency of using the mouse. It would be wrong to say that just because there is already one efficent way to use the program all the other modes to use it can be neglected.
I think you have to concider who uses the software and how. I have no real proof, but I believe the majority of users use the mouse, mainly for transcriptions, putting sheet music in a nice printable form or try out melodies and experiment with them. The powerusers will use the keyboard for fast engraving but I think for refinement they too do use the mouse.
Maybe it would be wise to put this discussion out into the open and see how the users of musescore think about this. I think this is very important, because once the decision which way to go is made, there is no turning back.

[MarcSabatella]

I disagree that the primary goal is "efficiency with the mouse", for exactly the reasons I already explained, so I won't repeat them. I also disagree that people who care about efficiency are better off with LilyPond or that such a comparison is relevant. And I disagree that only power users understand the value of the keyboard, or that they abandon this realization when "refining".

But I do agree more input is important. That is why I did start a forum thread, referenced in the initial PR comment above. Unfortunately I got little feedback.

[19joho66]

Thank you for your strong opinion.
I guess you're right so I will rest my case...

[MarcSabatella]

I would encourage you to try to get more feedback on the thread I started. I do still think it's an important issue to address, and I do like the idea of also making duration easier to set by mouse. But as this discussion shows, there can definitely be different ideas about the best solution, and it's clear at this point there isn't a real consensus, so hopefully more discussion will allow us to figure out something for the next release.

[Jojo-Schmitz]

You'd probably need to rebase to the new 2.3 branch

[lasconic]

If you rebase, please use master branch. Don't use 2.x branches for new features.

[anatoly-os]

@MarcSabatella it is good time to rebase on top of master and give testing a try.

[MarcSabatella]

OK. I don't know how useful or discoverable this really is, but it's harmless in any case.

[MarcSabatella]

Well, that was interesting :-) Will try again...