Replacing a note with an accidental leaves accidental on new note

• Dec 4, 2019 - 19:46
Reported version
S4 - Minor

Insert a note with an accidental attached to it
Select the note in any way (includes in note input mode) and select a different note name

Result: Note has the same accidental applied
Expected: The accidental should need to be reselected to apply it to another note

Original discussion can be found in I made the frequency few for both me and BSG.


I don't see this in note input mode, at least not in 3.3.4 (but I don't think that changed). But I can confirm in normal mode. Same basic issue as Shift+letter that we discussed earlier. Maybe all entry of notes by typing a letter from normal mode should ignore the toolbar accidental, since it is relevant to the current note.

Well, yes there was, because the toolbar accidental selects itself when navigating, just like the duration buttons do. They show you the duration and pitch of the current note. So just as typing "D" with an eighth note selected enters an eighth note because eighth note is what is selected on the toolbar when you selected the note, so typing "D" with a sharped note selected enters a D#, because sharp is what is selected on the toolbar when you selected the note. Somehow the first seems expected and the second doesn't even though it's the same concept, so I'd recommend we ignore the accidental state on the toolbar when entering a pitch form normal mode.

If you really want to have an accidental for the new note, press N first, and select the accidental that you want before entering the note.

What I would do if it were fixed is type the new note and raise or lower it with arrow keys.

That's the same problem as not pressing the accidental first before applying a note. It doesn't do courtesy accidentals or doubles. I'm not sure this is the right fix. I lean towards Marc's solution of apply accidental/duration now via a shortcut or even a toolbar icon.

I'm not sure this is the right fix.

The code change that I have proposed is good. It moves a line of code to the proper place, and removes duplicate code. What could possibly be wrong with that?

The recommended way to enter a note with an accidental is to begin note input mode, select the accidental, and then enter the note. However, I understand that people are used to the old behavior. I'm not sure whether we want an "apply input state" command or 5 new commands: "apply sharp", "apply flat", "apply double sharp", "apply double flat", and "apply natural", but I lean towards the latter.

What could be wrong? The accidental button is pressed on the toolbar, which should mean that entering a note will apply the accidental to that note. This fix fundamentally changes the input method for one case.

I sympathize with BSG and even preferred the previous input method of enter a note then enter the accidental, but the current method is logical and what we have. There are just a couple of specifics that need fixed.

The accidental button is pressed on the toolbar, which should mean that entering a note will apply the accidental to that note.

That is true only in note input mode. This issue is about entering a note from normal mode.

I would appreciate input from people who want this note input mode like Anatoly or Tantacrul. It's definitely related and should be consistent in my opinion, which I don't believe this is.

Where is the inconsistency? Is it about the accidental buttons behaving one way in note input mode and another way in normal mode? Because that really does make sense -- at least it does to me.

Status PR created fixed

Fixed in branch master, commit 05ed180bc6

_fix #298115: Replacing a note with an accidental leaves accidental on new note


This makes sure that ScoreView::startNoteEntry() clears the accidental state. Since this function already properly sets the duration and rest states, none of this needs to happen directly from within ScoreView::cmd()._

So you did an end-around and bi-passed Anatoly

I am not sure I understand what you mean. If you did not want this fixed, then why create the issue report?

I only asked for more than 1 opinion on how to fix it. But you decided that wouldn't be acceptable so you got dimirio to push the PR.

I still don't understand why you do not agree with my solution. What is there even to disagree about? Do you even understand why it behaved the way it did and why my fix works?

It now works the way it should have done from the start. That is, it now behaves the way I originally intended when I implemented the new note input workflow.

I am also not sure what the disagreement is about, but for the record, I also thought this was the correct solution and what should have been implemented from the start. This was discussed on forums, in the issue tracker, and on Telegram, and there was pretty widespread agreement. I don't even recall there being any other solutions proposed, and it's kind of hard for me to imagine what an alternative solution would even look like. Either we honor the accidental state - in which case we have the problem described in this issue - or we don't, in which case we have the fix that was implemented.

I have pushed this fix because it seemed completely logical to me. In normal mode accidental buttons state refers to the currently selected note (this is exactly what allows toggling accidentals for selected notes), and in note input mode it refers to the note which is about to be entered (which allows entering a note with correct accidentals right away and makes mouse input more intuitive). There seem to be no conceptual reasons why accidental buttons should apply to the note which is being added in normal mode. The proposed patch also does not really add any special handling for this case but just makes things more logical and consistent in the code. So I did not think of any issues that could possibly arise from this fix, although I did not read the full thread and thus missed possible objections, sorry for that!

As far as I understand, the main objection about this fix is that it does not allow something like "double-sharp shortcut"+"note name shortcut" work the same way as it would if entering Note input mode first. Still I would admit that such shortcuts usage wouldn't work consistently even without this fix, as:
1) Accidental shortcuts work as toggles on the currently selected notes (if any) in normal mode, so attempting to press "accidental shortcut"+"Shift+letter" to add a note with accidental to a current chord will alter the existing note accidental, which is unlikely to be expected and which wouldn't happen in note input mode;
2) If a note already has this accidental, pressing an accidental shortcut would actually turn it off so this shortcuts sequence wouldn't be reliable for replacing notes;
3) If one does not press an accidental shortcut and presses a note name shortcut while a note with accidental is selected, that accidental would be added to the new note (which is exactly what the initial bug report mentions here).

The first issue actually contains contradicting requirements: accidental state should apply to the existing note (from the "normal" mode paradigm) and to the new note (if that shortcut sequence is supposed to work), but not to both of them (as user probably intends to either alter the first note or apply accidental to the second one, not both). So resolving it in a consistent way would require changing something more fundamental like splitting accidental shortcuts to those modifying the existing or new notes, or forbidding to add notes while being out of note input mode at all. However I don't believe that this issue alone is serious enough to require such changes, although adding extra shortcuts which would always apply accidentals to existing notes might indeed be reasonable to consider. It looks like #297458: Feature Request: New set of shortcut commands to "apply" accidentals in note-entry is exactly about that. Otherwise the proposed pull request and a recommendation to enter note input mode for adding accidentals to new notes is the most reasonable solution here.

Hope this clear the confusion, and sorry again for not noticing this discussion before applying a fix.

Fix version