Right click menu in note entry mode and shadow notes

• Feb 24, 2016 - 17:19

This is not really a feature request, but rather something I've already programmed and I'd like to know what you think about this or if you have any ideas for addions or improvements. I've implemented a right click context menu in note entry mode and shadow notes which represent the set duration while in note entry mode.

1. A new menu entry in the right click context menu (which opens up if you right click in the empty space while in note edit mode) enables the user to switch to note entry mode

1.png

I've already received a suggestion to implement this for all right click menues in note edit mode.

2. A right click with the mouse in note entry mode opens a context toolbar which allows the user to change duration, dots, accidentials, voices etc. on the note entry spot. The user can also exit the note entry mode, do some editing and reenter note entry mode by using the new menu entry introduced in 1.

2.png

3. If the user changes the duration of a note in note entry mode, the shadow note now shows the right note and not just a filled or empty note head.

3.png

Cheers
19joho66


Comments

I really like the shadow note idea!

I'm not sure the right-click toolbar is really necessary though (did you know you can drag the existing toolbar and put it wherever you want?) but I could see something similar being helpful on touch screen devices. On a touch screen, you could tap on a measure and then the possible note durations could appear as a menu radially around the touch position. Editing scores on a phone/tablet is probably not something you'll see in the next couple of years though.

In reply to by shoogle

Hi shoogle,

thanks for your comment.

The advantage of a right click context menu is, that you can do the selection on the spot where you enter the next note. After the selection the context menu disapears. A dragged toolbar doesn't do this and often is in the way somehow and then has to be moved.

In reply to by shoogle

I suppose that could actually be quite handy, especially on a laptop with a bad trackpad. What about making it so that the menu also pops up if you hold down left click? (Maybe if you hold it for 500 ms?) That would make it accessible on a touch screen too.

In reply to by shoogle

I don't know, it probably depends on the OS. I don't see how it would interfere with normal use since you would normally just click and release straight away (not hold the mouse button down). It's just something I though of a while ago for an interface for editing within the Android/iPhone apps. Holding your finger down could cause the different note durations to appear in a ring around the point of contact, then you move your finger to the one you want and release. If you lift your finger without moving it then the currently selected duration is used, so again it wouldn't interfere with normal use. The suggestion here is slightly different - hold for the menu, then release, then click the menu item - but either way would work.

In reply to by shoogle

You could make the same argument for many other contexts, in many other programs, but there's a reason that absolutely no application does this. A right-click is a right-click. Some systems may have different actions that access the secondary-click function (for example, on my laptop, it's a two-finger click), but that applies globally anywhere in the OS. A single application in which a long left-click turns into a right-click? That application would be annoying a lot of people. If you want that behavior, configure your system to support it. The idea of any desktop application doing this on its own is very surprising.

In reply to by shoogle

Secondary-click usually accesses a context menu, not a toolbar, so this would already be breaking a convention. In MS Word, highlighting a word (i.e. with left-click) displays a toolbar (see image), so I think left-click-and-hold, would actually feel more natural (or maybe even have the toolbar permanently floating at the current note entry point?). Right-click would be more annoying for me because I often press right-click by accident, but I never accidentally left-click-and-hold.

But I wouldn't want to just assume that what you or I find annoying is true for everyone, which I why I would like both to be enabled for testing within the nightly build. We decide which works best and disable the other in the final release. If we want to innovate then we need to be prepared to try new things.

Attachment Size
word.png 38.34 KB

In reply to by shoogle

I want to affirm that the concept of right click should be something that the windowing environment tells mscore through Qt immediatery. Not something that mscore tries to figure out on its own.

The android X-Servers and VNC's that I've tried out all have their own special way in settings to configure how to input right click (be it two fingers, double tap, tap in right side of screen, etc.). Additionally my bluetooth mouse has a right mouse button that works in my android X-server. And mac's I believe have their own way using Ctrl->click (I think).

Having access to the note-entry menu wherever the mouse pointer happens to be is great.

In reply to by ericfontainejazz

Sorry, I think you got the wrong idea about what I was suggesting. I just want the toolbar to be displayed by holding left click. I don't want left-click-and-hold to somehow emulate a right-click. I want right-click to do *absolutely nothing* (or maybe it would show a context menu, if relevant). Again, I point to the example of Microsoft Word where interaction with the left mouse button displays a toolbar at the editing position, and right-click only ever shows a context menu.

However, for the purposes of testing the feature (rather than just discussing it) I suggested enabling both options so that we could actually see what worked best by trying it out.

In reply to by shoogle

Well, you did initially suggest it as "What about making it so that the menu also pops up if you hold down left click? (Maybe if you hold it for 500 ms?) That would make it accessible on a touch screen too," which I interpreted the same way Eric did. But temporarily implementing it both ways seems fair enough.

However, now I'm thinking about it further, I'm not sure how it would work. We're clear that this would only be available when in note input mode, right? And when in note input mode, left-clicking enters a note.

So you click, a note is added, hold, and then the note is deleted as the context toolbar pops up, allowing you to enter a note again—by clicking… and to get the toolbar back you click and hold again? Like I said earlier, there are reasons this isn't a thing already.

In reply to by Isaac Weiss

That shouldn't be too hard to change, but I'm actually starting to prefer the idea of having the toolbar float permanently just above the stave at the current editing position. This seems easiest of all and avoids the problem of discovery where users might not realise that they can right-click or left-click-and-hold to get a toolbar.

In reply to by shoogle

I have to say out front that I don't like that idea. Changing something as fundamental as note input shouldn't casually "overwrite" a previously familiar interface, and that's exactly what that would do. Having that thing always floating there, following me wherever I go, always blocking my view of the score, just seems like an unutterably bad idea. Remember, the toolbar already is always present!

In reply to by Isaac Weiss

An option of having toolbar appear to float above the staff is interesting, but I would like to be able to disable that, and would like to be able to configure the delay in milliseconds after which the toolbar appears (0ms for instantaneous/permanent).

I agree with Zack's caution, that I wouln't want to "overwrite" a previously familiar interface.

In reply to by Isaac Weiss

I try my best to avoid it too, but I have to admit that MS Office is still way ahead of LibreOffice/OpenOffice. The floating menu is particularly nice, as is the ribbon interface (or it would be if they didn't keep messing with it).

A danger I see with the right-click toolbar is how to make it disappear if I didn't mean to right-click? Obviously I left-click somewhere else. But wherever I click a note will be added to the score. Now that would be annoying!

In reply to by shoogle

>> "A danger I see with the right-click toolbar is how to make it disappear if I didn't mean to right-click?"

But I was actually concerned a little bit with having the floating toolbar always appear above staff: What if it is appearing ontop of some chord symbols or staff/system text that I want to edit?

So if I find the toobar is getting in my way a lot, I'd like to disable it.

In reply to by shoogle

I don't doubt that Microsoft Office is still way ahead of LibreOffice (obviously it's ahead of OpenOffice). But at the same time, LibreOffice is significantly ahead of Microsoft Office (see http://www.datamation.com/applications/how-libreoffice-writer-tops-ms-w… for example). And at the same time, they really do have a 95-99% overlap in features (and I don't exaggerate numbers). I gather you like Microsoft's extra 5%. I like the ability to open AppleWorks documents. ;-)

Well, that was a nice birdwalk.

In reply to by Isaac Weiss

You're right, the gap is closing all the time, but for advanced users I don't think it's quite there yet. In terms of features they are more-or-less equivalent, but I find MS Office is far more polished. LibreOffice has some annoying bugs in basic features, like displaying PNGs with transparency. I find Microsoft's ribbon interface to be far superior to the 1990's style toolbars and menus that LibreOffice still insists on using. Excel and PowerPoint have better looking templates for graphs and presentations than LibreOffice Calc and Impress, etc. I mainly just use Google Docs now anyway, because its sharing a coloration features are unrivalled, but when I need something more powerful I end up using MS Office.

Anyway, back on topic...

In reply to by shoogle

The PNG thing seems to be a regression that only exists in one release from the "fresh" branch, and will presumably be fixed by the time it becomes the "still" branch (which is, after all, what they recommend for professional use). But isn't there another program that uses menus, one that saves files with the extension MSCZ? ;-)

In reply to by Isaac Weiss

Indeed there is! But MuseScore's buttons are distributed among a number of windows and dockable panes rather than all jammed into one huge toolbar at the top. The best examples are the inspector, which only shows controls relevant to the current selection, and the Pallet pane, which allows irrelevant categories to be collapsed when not needed. This is analogous to how the ribbon interface in MS Office only displays buttons that are relevant to the current mode or selected item (e.g. Word has ribbon menus for Insert, Design and Page Layout, etc). There's still room for improvement though; ideally each mode would only show relevant options and nothing else, entering Playback mode could hide the Inspector and Palette panes for example.

Like ;-)

(because I rather use the mouse pad than shortcuts or midi input for note entry and editing on my laptop).

I'm all for both ideas. However, in the last two screenshots, there's a vertical line partway through the staff to the right of the time signature. What's going on with that?

I've been persuaded that the shadow notes and floating toolbar are welcome additions (though I think the toolbar should appear on left-click-and-hold rather than right-click, or maybe even just permanently float above the current note-entry point), but I'm unconvinced by the right-click option to enter note entry mode when there is already the keyboard shortcut "N" readily available. We wouldn't want the right-click menu to get too cluttered (e.g. Playback mode, Replace Pitches mode, and, when it arrives, Real Time Note Entry mode). Any thoughts on this?

In reply to by shoogle

-- didn't mean to reply here...my comment is a new one at top-level of this thread https://musescore.org/en/node/99536#comment-442861 --

Regarding: "but I'm unconvinced by the right-click option to enter note entry mode when there is already the keyboard shortcut "N" readily available."

I would say there are definate use cases where don't have easy access to keyboard, which I've encountered, incuding:

  1. I have my labtop sitting ontop of my keyboard (where music stand usually is), and have my mouse to my right side. In this case I usually have one hand playing notes on keyboard, but the right hand might just want to access mouse instead of have to reach all the way to top of keyboard
  2. I'm on android chroot with limited screen space so don't want to bring up virtual keyboard, and I don't have a blutooth keyboard at the moment I want to use mscore. In that case, I'd like to be able to do as much with just mouse input

I'm copying my comments I made on jho's PR "Shadownotes during note entry #2313":

I've tested out your PR, and I like it. It lets me know what duration I've selected, so I don't have to move my eyeballs at the toolbar if I can't remember what duration I had selected.

and on his PR "Right click menu in note entry mode #2401":

I've tried out your PR, and I like it alot...definatley saves a lot of mouse work, especially for users who are avoiding keyboard.

One suggestion for your PR is that I'm only able to enter "Note Input Mode" if I right click on an empty space between systems, but it would be much more easier to access if I could right click anywhere and find the "Note Input Mode" button in menu. Currently if I right click on a measure (on the staff or between staffs in a system), I am unable to access "Note Input Mode".

Regardin what should be in the context menu, I also wrote:

I fear there will never be an agreement as to what exactly should belong there and not belong [in the right-click menu]. Do [anyone] know how feasabile it would be to allow the context menu to be user-configurable via Preferences or .ini

I think that new users might be overwheleved if there is too much stuff in right-click menu, due to information overload. But I also feel that pro-users will want all these extra things to improve efficiency. Mscore already does something similar with the Pallete (starts in default beginner mode as, but user can change to advanced mode and add custom palletes).

In reply to by ericfontainejazz

I think right click context menues are a great way to speed up the workflow if you use the mouse. I use REAPER a lot and there the right click context menues are used extensively. Specialized context menues makes it uneccessary to use the menubar at all. The use of a menubar always involves the moving away from the element you are working on, clicking several times through the main menu until you get the entry you need and then you have to go back and find the element again. With a right click context menu, you just click right once and have all the relevant commands at the spot where your element is. After selecting the command the menu is gone and you can go ahead in your workflow.

I got so used to this, that if I want to do anything in REAPER I first use the right click to see if the desired command is in the context menu. (And in 95% of the cases it is).

That is also the reason why I came up with the idea of a context menu in the note entry mode. I really missed this feature.

In reply to by 19JoHo66

I'm not disagreeing with you, and I support your PR, although the one thing I think needs to be fixed before merging is:

One suggestion for your PR is that I'm only able to enter "Note Input Mode" if I right click on an empty space between systems, but it would be much more easier to access if I could right click anywhere and find the "Note Input Mode" button in menu.

In reply to by 19JoHo66

I don't know what the rules are about PR. lasonic is the person who merges PRs. I always just squash & recommit to the PR branch when I'm ready, and no one has said anything to me about that. Although all the core developers get an email when the travis build completes, so best to not recommit to the PR too often.

In reply to by 19JoHo66

Just add your changes to the last commit with `git commit --amend`, or create a new commit and then squash with the previous with `git rebase -i HEAD~2`. Probably a good idea to rebase against upstream:master at the same time, then push back to the same branch with `git push -f <branch>`. If you're worried about sending too many notifications then create another branch to run your own tests and then cherry-pick commits back into the issue branch, but probably needn't bother doing that here since you can just run the tests locally.

Maybe leave a note on the PR to say if you might make some more changes or if you think it's ready to merge.

In reply to by Jojo-Schmitz

The shadow note duration is now merged on master.
Note that

1/ it doesn't include dots
2/ it doesn't move the mouse automatically like the original PR was doing.

I used it quite a bit during the past 2-3 days and I'm not yet 100% convinced that it's an improvement. So feedback is still welcome.

In reply to by Isaac Weiss

I'm not sure it's worth trying to calculate the stem direction, since it depends on many factors (position in staff, voice, also beam status which could well include notes not yet entered). I think it would be a lot of work to still not always be "right", and in any event, I sincerely doubt it will be seen as confusing that the stem flips. More disorienting to see if change as you drag actually. And besides, it's not like the toolbar icons change.

In reply to by Marc Sabatella

I've done an in-depth comparison between the major scorewriters, and I recorded GIFs of what their "shadow notes" do, inputting an eighth note D4 followed by a dotted quarter F4.

These are in order from worst to best, as I see them.

1. MuseScore 2.0.3:

mus2.gif

Notehead only. No stem, no flag, no dot. Not good.

2. Nightly eaa0322, post-19joho66's improvements:

mus3.gif

Stem and flag included. Still no dot, so duration is not all there. Stem direction does not match staff position.

3. Finale:

fin_converted.gif

Stem, flag, and dot all included. Stem direction does not match staff position.

4. Sibelius:

sib.gif

The ideal. Stem, flag, dot, and stem direction all together, showing you exactly what's going to be placed on the staff.

In reply to by Isaac Weiss

Just curious how accurate Sibelius' stem direction is if the note is part of a beam group. Obviously, it can't know what notes will be entered later so it's going to be wrong a lot regarding the *final* position, but I suppose it could get it right regaridng the *initial* position. Like, if you enter eighth notes, two middle C's, then a C an octave higher - does it correctly show you the stem will actually be up, at least initially?

In reply to by Isaac Weiss

Agree for stem direction, and dot.
From my part, I am also and maybe more disturbed by this behavior in a multivoice context (and on a single staff), essential in the guitar writing.
This behavior adds a regrettable visual confusion to the entering of notes, by creating collision between notes (at least, a part of noteheads, and flags etc.) And I am not a big fan of collisions of all kinds!
Of course, I just begin to test this. But the very first impression is not good here, sorry.

Some examples:
With the 2.0.3:
Ok voix 3.jpg
Currently (last nightly f97b265 )
NON, voix 3.jpg

Other, with the 2.0.3:
OK version 22.jpg
Currently:
NON version 23.jpg

In reply to by cadiz1

I just added stem direction and dots.
The algorithm for stem direction is simple (maybe too simple). Voice 2 and 4 are always down. Voice 3 always up. Voice 1 is up below above middle B in G clef, down above. And so it's ugly if the chord change direction with the new note... Feedback very welcome. The more I see it, the more I like the 2.0 implementation.

In reply to by Isaac Weiss

I know I initially expressed support, but after I've read cadiz's comments, I'm also noticing that things can at times be a little too cluttered, especially when there is already a lot of ink already. Anyway, I think there should be a preference to disable shadow notes if not wanted, but I know I have the minority viewpoint about allowing most things to be configurable.

I like how sibelius is using a light grey for their shadow notes. I sortof find that easier on the eyes than the full color which musescore is using now. I'm thinking maybe having the shadow notes be colored in a light grey will alleviate some of the information overload.

(I presume those rectangles are just being use now for debugging purposes, since it reminds me of what happens when I run older musescore in debug with -d command line flag.)

In reply to by Jojo-Schmitz

By trying again, I started bitching ... Because the blue color of the Voice1, now, was the same like the instruments names, time signatures, etc. in the Continuous View (and I don't like it yet, because too washed out, and because the blue - this blue- is always showed, and re-showed, into the instrument forums and other forums of all kinds ...) Anyway, personal feeling!

Before I realized that after the entry of the note, this note (notehead) reverted its original color, more intense, a true color, what!
bleu 2.jpg
The same for the other voices (and colors)
I suppose of course that this is intentional! And I must admit that it's rather well done!

These "translucent" colors ( (including stems and flags, which was my main complaint in a previous message) have the power to reduce the impact of the possible information overload and visual inconfort (I mean mainly in a multi-voice context). Of course, the improvment of the stem direction participe to this.

I will issue perhaps some reservations (or not) after further testing, but for now, I feel much better than yesterday noon!

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