Over-eager "remove" in Instruments dialog.

• Feb 27, 2020 - 14:55

(3.4) I was trying to delete many parts from a score with many parts, just saving a few. I carefully deleted the few above the parts I wanted to keep, and then clicked on the first one after them that i didn't want to keep, and clicked "Remove" many times. Surprise! Once it got to the bottom, it started removing parts upward, i.e., the ones I wanted to keep. This is not right. If you Remove the last part, it should not leave any part selected. I had to count very carefully to achieve the simple thing that I wanted, and do it two or three times until I understood it was trouble "not with my set, but the station" (as they used to say in the days of broadcast TV).


Comments

In reply to by bobjp

I'm talking about instruments in the instruments dialog, not files. It is no quicker to delete the last one up than the first one down. It is contentious because some think it right, and I think it wrong. I am not an ignorant naif; I have been designing software and using multiple operating systems for a very long time, and the "designers" are not long-departed gods whose opinion is to be taken as gospel and not open to reevaluation, as evidenced by the fact that pretty basic UI artifacts do get revised here by discussion regularly. A user gesture that changes meaning if you don't count carefully and starts eating the ceiling instead of the floor is dangerous and counterintutive. It should stop when it reaches the bottom; you may disagree, but the argument that "the designers thought it best" means nothing to me; this is open source, not Microsoft.

On all editors I have ever used, not one starts deleting lines upward when you delete successive lines toward the bottom and delete them all.

In reply to by [DELETED] 1831606

A user gesture that changes meaning if you don't count carefully and starts eating the ceiling instead of the floor is dangerous and counterintutive.

I do not think that it changes meaning, and I do not find it counterintuitive.

On all editors I have ever used, not one starts deleting lines upward when you delete successive lines toward the bottom and delete them all.

This surprises me. I take it you have never used vi?

In reply to by [DELETED] 1831606

BSG. "I am not an ignorant naif". Certainly not. Please don't read into my post things that are not there. I can't presume to have used MuseScore as long as you. Yet I noted this behaviour early on and adjusted to it. I can not claim to have the apparent programming prowess you possess. Yet it is clear to me that there is a wide lack of standardization across the software industry. Possibly because programmers believe their way is right and others are wrong. Mere mortals such as myself, have to adapt or perish.
OTOH, consider posting this in the Feature Request forum instead.

In reply to by bobjp

Mere mortals like myself are subject to being convinced by other mortals whose opinion I respect, and acknowledge being in the minority on this on the basis of the other arguments (I didn't find your quicker/more convenient argument convincing). So I will learn to live with it the way it is.

In reply to by [DELETED] 1831606

Well-informed, to be sure. By more convenient, I meant that when deleting a list of 15 or so individual fonts ( as you know, not all collections are in one file) I can select the last one and just keep hitting delete. Otherwise, I have to select/delete, select/delete ......on and on. I agree it would be easier to be able to select a range.

In reply to by bobjp

What about if you only want to delete the last 7 of the fifteen fonts (or instruments)? Often I want to extract a couple of important voices from a score, and delete all the rest. Since copy-paste of arbitrary stuff doesn't really work, deleting ones I don't want is natural. I don't want to delete all , just the ones up to my point of interest and after. You say "keep hitting delete". That's exactly what i was doing, starting on the first one I didn't want, and I just "kept hitting delete", and lost (not badly, I just had to cancel the dialog). But, the consensus here says that that's not as important as the other expectability criteria, so, I'll just be more careful.

In reply to by bobjp

Possibly because programmers believe their way is right and others are wrong.

I do not believe this to be the case, being a programmer myself. Rather, programmers believe that if it works the way it was designed, then there is no problem. It is up to designers to try to achieve standardization across the software industry. Lack of standardization comes about when programmers are forced to create a design on their own due to lack of designers.

From an accessibility standpoint, it is usually best to avoid the deselecting things when there is any doubt, as to me there is here. That said, I see your point. Would be interesting to compare to behavior in similar elements in other apps. FWIW, though, this dialog is in the process of being redesigned entirely.

In reply to by [DELETED] 1831606

It cuts both ways to be sure. In situations where there is a very clear reason to expect the selection to be cleared, it can indeed be dangerous to select something. Thus, for example, in a page layout / desktop publishing / drawing app - something that places multiple objects on a canvas - you expect that if you click something and press Delete, it's gone, and nothing else is selected in its place, so subsequent presses of Delete will do nothing. And yet, in a word processor, the cursor is expect to always be present, so pressing Delete multiple times will delete multiple elements. A musical sccore has elements of each, and we've had to think hard about such issues as, what happens to the selection if you click a dynamic marking (or other element) and press Delete. We use to leave nothing selected, more like the drawing program model, but based on feedback, have moved to the current model where in most cases we select something else for you - so more like the word processor model.

The instrument list is just a list, neither a drawing canvas nor a text document, and so it has its own expectations. In theory it should be a simple matter to find similar objects to compare with. Offhand, the first that occurs to me is an email app showing emails in a list. If you click the last email to select it and press Delete, what happens? I just tried with Outlook, it selects the new last element - so, same behavior as our instrument list. In Gmail, the Delete key isn't actually active, and it provides two separate commands to delete and move the selection up or down, so you can control the behavior according to which key you press. The delete button in the app leaves nothing selected after deletion, but this is true regardless of whether you are deleting the first, last, or some other message.

I also tried the Files app on my Chromebook. Selecting an element and pressing delete leaves another selected, regardless of whether firs, last, or other. So, same as us. Whereas the Linux/Nautilus Files app leaves nothing selected - againm, regardless of position in list

So far, then, I am not finding any examples of apps that special=-case the last element of a list with regard to delete. They either always select something else or never do.

In reply to by Marc Sabatella

When I open the dialog, nothing is selected, so this is a valid state, not an unexpectable anomaly. I'm glad Emacs or the edit windows on the Mac don't start deleting every line in the buffer if I type control K or control D "too many times". I guess I'm in the minority and will just have to learn not to use "Remove" with quickly repeated presses.

In reply to by [DELETED] 1831606

Yes, the initial state is no selection, and the fact that it's even possible to have a "nothing selected" state is one of the things that makes it unlike a text editor. Text editors are, as I mentioned previously, quite different, because the cursor is always present. So there is no such thing as losing selection in the same sense. Plus text editors - on systems other than macOS, anyhow - generally have a clearly defined difference between Backspace versus Delete. So analogies to text editors really aren't relevant. Better to think of comparisons to the types of application I mentioned - things presenting discrete elements in an ordered list, in which there can either be something selected or not, and the behavior of the Delete depends on wther something is selected or not, as opposed to depending on a "cursor" position.

In reply to by [DELETED] 1831606

Making analogies to text editors will continue to miss the point, because as mentioned they are entirely different. List widgets do not have a "cursor" that exists between two elements from which you can delete "forward" or "backwards", they have a selection that you delete in place, period. The only question is whether something else gets selected after the deletion. And as the example I posted make clear, most programs that provide list of elements that can be deleted work consistently here. Either deletion never selects another element, or it always does - it virtually never behaves differently depending on whether the selected element happened to be last in the list or not.

Try it yourself with the apps I mentioned, or feel free to suggest other non-Mac-specific apps I could try that also provide a list-based model (based on selections) as opposed to a text-based model (based on cursors).

In reply to by Marc Sabatella

Outlook autoselects the next email after delete because most often the user is busy to read email by email.
Being in a loop:
[ Read --- delete or go to next (arrow) ] repeat for all unread.
Without autoselect user would need to manually reselect between each email making the process a lot heavier.

In discrete lists where that [read loop] is not the daily (hourly) common process, autoselect after delete can Indeed seems more harmful than beneficial.

Which doesn't mean that the recent change for items selected in score is bad. There it perfectly makes sense to autoselect after delete because even if the selected item in score is not a true cursor, its usage and therefore expected behaviour is similar.

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