Focus should move to note when articulation is deleted via selection
I am glad to notice that now when an operation is performed on a note, the note remains selected. Thank you.
When I select an articulation and delete it using "delete", the focus in on nothing until I click something. It would be preferable if the focus automatically switched to the note that was just edited. It would not interfere with selecting another note if that was what you wished and would remove one more instance where one has to switch from keyboard to mouse for navigation.
Comments
Another place where the focus would be better kept is when one clicks outside of a chordname box when one wants to leave that entry system. At the moment, focus is again lost.
In reply to Another place where the focus by xavierjazz
On re-reading my original post, I see that I suggested moving to a "note". What I really meant is the focus should move to that same moment in time, note or rest.
While I agree that sometimes it might seem ncie for deleting an object to leave something else selected, this is actually non-standard behavior across most applications, and it creates a usability issue where pressing Delete multiple times would then delete multiple objects. This is normal only for text editors or similar programs that involve a cursor. But most graphics-oriented program do not behave that way.
That said, again, I agree it sometimes seems it would be nice to do something like this anyhow, or at least, to find some other solution to the issue of needing the mouse to reselect. One possiblility is to add an "unescape" command that selects the most logical thing to select at any given moment if nothing is currently selected - presumably using some combination of remembering state from the last selection, or some variation of the same algorithm used to select a starting point for note input if you forget to select one yourself.
In reply to While I agree that sometimes by Marc Sabatella
Re: " .... it creates a usability issue where pressing Delete multiple times would then delete multiple objects."
I do not think this is an issue. The only way I could see that happening without being clear and instantly reversible is if the element focused on was somehow outside of the viewing area. In general if it were implemented, the delete "error" would be instantly apparent as it is the note being adjusted. If the note were deleted through error, the rest would then be the focus and further presses would not cause random errors.
In reply to Re: " .... it creates a by xavierjazz
I didn't mention it, but one concern I specifically had in mind was blind users - they often depend on predictable behavior and cannot rely on visual feedback. But again, I certainly sympathize with the desire to not need the mouse. Might be interesting to see how other applications (but notation programs but also grahpics editors etc) deal with this.
In reply to I didn't mention it, but one by Marc Sabatella
Hi Marc, I don't really understand your point re: blind people.
At the moment the default is "no focus". I requested a focus.
I don't understand how the 1st improves on the 2nd, although I am not blind (just severely myopic). Perhaps I just am missing something.
As to other applications, someone has to be first. An improvement will be noted and followed.
Regards,
In reply to Hi Marc, I don't really by xavierjazz
After selecting an element and hitting delete to delete it, a user might accidentally hit delete again, or - specifically for blind users - they might not not be sure the first one worked and so deliberately hit delete again. Normally this is completely safe - hitting delete multiple times always does the same as hitting it once. That's true for most applications. So it's a little dangerous to deviate from that standard - if we do, then hitting delete multiple times would no longer be safe. But again, I agree that for most of us, it might seem an improvement, and as you say, someone has to be first. Still I doubt we actually would be the first, so it wouldn't hurt to see how others handle this.
In reply to After selecting an element by Marc Sabatella
:)
In reply to After selecting an element by Marc Sabatella
We already refocus when deleting a note from a chord, and, to clarify, I don't mean only single-note chords.
In reply to We already refocus when by Fyrult
Hi, and thanks. My comments are quite specific as to the cases I've noticed.
In reply to Hi, and thanks. My comments by xavierjazz
Ah, I meant that as a reply to Marc, that we already "deviate from that standard".
In reply to Ah, I meant that as a reply by Fyrult
Ah. :)
In reply to We already refocus when by Fyrult
Yes, that change to select a rest when deleting a note is a relatively recent change - I think added for 2.0.1? It is a "safer" change in the sense I am talking about, though, since with a rest selected after pressing Delete, a second press of Delete won't actually do anything.
Again, it's not out of the question to auto-select something else after pressing delete - could even be a program preference if we want to preserve the current behavior for the benefit of the visually imparied or others who give especially high importance to UI consistency across applications. I'm just saying, there actually *is* a reaosn we don't don't do this already, and why we would want to think carefully before doing so now.
In reply to Yes, that change to select a by Marc Sabatella
This is what I mean:
before:
NOT FOUND: 2
press "Delete" twice:
NOT FOUND: 1
After the first delete of the G, the focus is on the E. The second delete removes the E.
In reply to This is what I by Fyrult
Ah, yes, then indeed, that's a place already where we do this. And so far, no one has complained. So that's a good sign :-)
In reply to I didn't mention it, but one by Marc Sabatella
'I specifically had in mind was blind users'
The intention is laudable, but blind users of computers are used to type in text, and in any text editors when they press twice delete they delete 2 characters, so I don't thing that it would a problem.
In reply to 'I specifically had in mind by frfancha
As I said, text editors are different. But most other programs do not work that way. I have worked with blind computer users perhaps more than some people, so I know that consistency of user interface is a hugely important issue that we cannot take lightly.
In reply to While I agree that sometimes by Marc Sabatella
"...creates a usability issue where pressing Delete multiple times would then delete multiple objects..." reminds me of #63681: Hitting Enter in Instruments dialog repeats "Add" or "Delete" instead of applying "OK".
In reply to "...creates a usability issue by Isaac Weiss
"...creates a usability issue where pressing Delete multiple times would then delete multiple objects..."
I still don't really understand this objection.
I do not conceive of this as constantly changing position in the bar or beyond by continually pressing delete.
I can see a possible problem if the focus changes withing a chord, but why would the focus change when a delete produces a rest?
Once a rest is selected there would be no effect unless it was in voice 2,3 or 4.
At any rate, overdoing deletes would be easily undone using "undo".
In reply to "...creates a usability issue by xavierjazz
Open your favorite program that is *not* a text editor. Say, a graphics editor, or a file browser. Click something, press Delete. Then press Delete again. Did two things get deleted? 90% of the time, the answer is "no".
That is the objection. Click an articvulation, press Delete, then press Delete again - two things get deleted, *unlike* how most program works. Again, I'm not saying it is completely out of the question that we might choose to have non-standard behavior here, but I can't think of any more clear way to explain that this really *is* an issue to be considered.
Yes, Undo is available, but this also presupposes that feedback is given that the Delete operation actually did anything. And it's still not ideal for users who rely on consistency. It really is important we at least think about these issues and not go out of way to make things harder.
I appreciate this request:
Currently, when I double click the incorrect fingering in the palette, I have to press delete, then nothing is selected and I have to use the mouse to select the note again, and move the mouse back to the palette to double click the corrrect fingering.
If after the delete of the fingering the note would be selected, I could just double click the correct fingering (near the mouse as I have just double clicked the incorrect one, so a very small move).
Excellent.
Tip: If, after applying fingering, you press [Ctr][Z] (Undo), instead of [Del], the focus returns to the note. This applies to articulations as well.
In reply to Tip: If, after applying by geetar
Thanks for the tip, indeed it helps when you have just added the incorrect fingering (the scenario I 've described)
But it doens't help when you are modifying fingerings (e.g. while playing and finding that another fingering would be better). In that case selecting the note after deleting the fingering would still be useful.