Over-eager "remove" in Instruments dialog.
(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
If you Remove the last part, it should not leave any part selected.
I disagree. In this case, the trouble really is with your set.
In reply to If you Remove the last part,… by mattmcclinch
I think that this is just the way MuseScore works. For example take the synthesizer. If you have several fonts loaded and you want to delete some. If you select the bottom font and hit Delete, the next font up is selected.
In reply to I think that this is just… by bobjp
Well, "that's just the way it works" doesn't mean its optimal, or not error-prone. Obviously, it's contentious.
In reply to Well, "that's just the way … by [DELETED] 1831606
Perhaps you find it "contentious" because you were surprised by it. I was surprised, also. But I found it to be quite a time saver, since selecting first and last files to be deleted does not also select the files in between. This behavior seems to be a choice by the developers.
In reply to Perhaps you find it … 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 I'm talking about… 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 A user gesture that changes… by mattmcclinch
I use it very rarely, only when forced. It is barely an editor. I guess my instincts are simply wrong. I concede.
In reply to I'm talking about… 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 BSG. "I am not an ignorant… 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 Mere mortals like myself are… by [DELETED] 1831606
I may be a well-informed naïf, though....: )
In reply to I may be a well-informed… 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 Well-informed, to be sure… by bobjp
I agree it would be easier to be able to select a range.
Not just a range, but multiple items which may or may not all be adjacent.
In reply to I agree it would be easier… by mattmcclinch
Non-adjacent items would be nice, too.
In reply to Non-adjacent items would be… by bobjp
For sure.
In reply to Well-informed, to be sure… 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 What about if you only want… by [DELETED] 1831606
Oh man. You had to go and bring up being careful. Are we not Men :-)
In reply to Oh man. You had to go and… by bobjp
Oh man. You had to go and bring up being careful. Are we not Men :-)
Don't worry. Being a risk-taker does not mean that you have to be careless.
In reply to Don't worry. Being a risk… by mattmcclinch
True. But it seems that no matter how careful I am, there's always someone trying to run into me on the freeway.
In reply to True. But it seems that no… by bobjp
Deleting unwanted instruments should incur minimal risk.
In reply to Deleting unwanted… by [DELETED] 1831606
Deleting anything should have minimal risk. I believe in undo buttons.
In reply to Deleting anything should… by bobjp
The instruments dialog lacks one.
In reply to The instruments dialog lacks… by [DELETED] 1831606
Do keyboard shortcuts work?
In reply to Do keyboard shortcuts work? by bobjp
No.
In reply to No. by [DELETED] 1831606
We hardly need to enable undo for changes that only happen within the dialog. Changes that are applied to the score can of course be undone.
In reply to We hardly need to enable… by mattmcclinch
Suppose there are many many parts, and you delete some, and move some around, and make a mistake. All the work is lost. The amount of losable "work" you can do in that dialog is nontrivial.
In reply to Suppose there are many many… by [DELETED] 1831606
I could see adding an Apply button to the Instruments dialog. That way, you can periodically "save your work" without having to close the window.
In reply to I could see adding an Apply… by mattmcclinch
Presumably, each "apply" could be undone outside the dialog.
In reply to Presumably, each "apply"… by [DELETED] 1831606
Of course.
In reply to BSG. "I am not an ignorant… 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 From an accessibility… by Marc Sabatella
Whew! = excellent, thanks. I would think a differently-abled user would be even more surprised by what I observed than was I.
In reply to Whew! = excellent, thanks. … 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 It cuts both ways to be sure… 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 When I open the dialog,… 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 When I open the dialog,… by [DELETED] 1831606
I would prefer the ability to select a range and remove it, and after a remove, nothing is selected.
In reply to I would prefer the ability… by [DELETED] 1831606
I'd take the ability to select a range or use multiselect. But, even so, I'd still want something selected after the delete, to make it easier to then make my next selection.
In reply to I'd take the ability to… by Marc Sabatella
If there were either form of multi-select, the temptation to delete successive elements and mess up would be removed, although some may still fall in the trap.
In reply to If there were either form of… by [DELETED] 1831606
I don't see a trap, though. It is more a case of the user tripping over his own feet.
In reply to I don't see a trap, though… by mattmcclinch
If you expect forward deletion to do just that, it is a trap. Maybe only we old-timers still mired in Emacs think that way.
In reply to If you expect forward… by [DELETED] 1831606
But this is not forward deletion. It is the deletion of a tree widget item. Not the same thing at all.
In reply to But this is not forward… by mattmcclinch
I'm not addressing its internal implementation. When I press delete twice, it deletes two elements forward. Unless I hit the bottom, when it effectively turns around. It walks like forward deletion, quacks like forward deletion, and goes well with hoisin sauce.
In reply to I'm not addressing its… 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 Making analogies to text… by Marc Sabatella
I "deleted forward" and got burned. Accident case history of 1. All right, don't "fix it", but create those better multi-delete tools we've been discussing.
In reply to I "deleted forward" and got… by [DELETED] 1831606
I don't see how that is going to help. Deleting one by one is sufficient, and it already works the way you should expect it to work.
In reply to I don't see how that is… by mattmcclinch
All right, I have to accept it as it is and learn to deal with it. It's not the end of the world, esp. considering the headlines these days.
In reply to It cuts both ways to be sure… 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.