Range selection includes invisible staffs
Currently when making a range selection in the score, invisible staffs may also be included and affected.
I've thought of some typical scenarios:
1. When you select all(via Ctrl+A). Currently all invisible staffs are affected.
2. When there're 3 staffs, with the middle one being invisible, and you select from the first to last(from what you see, the two staffs are adjacent). Currently the middle staff is also affected.
Potential questions to be discussed:
-
What's the user's intention in the above scenarios? More specifically, under what circumstances does the user want invisible staves to be affected?
-
If we want to ignore invisible staves in some situations, what changes should be made to class
Selection, or the codes that useSelection
Comments
Personally, if we pay no attention to the complexity of implementation, I would prefer to always ignore invisible staffs.
I think most people's intention is to select what they see when they are selecting something. And maybe it's weird to find you're actually selecting sth that you don't see...
Maybe one of the design purposes of "hiding a staff/layer", is to make it locked and protected. The layers in Adobe Flash are designed in this way.
And there're indeed some risks of including elements from invisible staffs in selection, which may cause problems like #287515: [Feedback Form] Crash on changing notes after transposition and #284012: Crash by editing/selecting entire score when another hidden staff contains beamed notes, where the invisible beam's parent is no longer
System, and some codes still try to interpret the parent asSystemwhen those invisible elements are selected. Though these 2 issues are possible to be solved via other approaches, like adding the consideration for the beam's parent's not beingSystem.However, including invisible staffs could indeed bring some convenience sometimes when we want to transpose the whole score after pressing Ctrl+A. But perhaps the user should really make other staves visible before doing that...
I don't see a scenario, where I would want to transpose the entire score and not transpose the invisible staves. Invisible does not equal muted. I may not remember that the staff is invisible, but if I transpose the entire score one full tone, but the invisible staves are not transposed, the score would become very dissonant.
Another reason for selecting an entire score that I've seen discussed on several occasions is to color code notes. I personally will hide a staff that I haven't use in sometime while writing my own music or transcribing a score. If the user were doing something like color coding the notes, their expectation would likely be that the hidden notes would also be color coded. When the staff is unhidden, the notes would be colored as expected.
The current results is that ctrl+a selects hidden staves and no one has reported this as a problem. A better question would be, "Why should we change what's not broken?"
In reply to I don't see a scenario,… by mike320
The time I use ctrl+a the most is when I import a score into version 3. I routinely press ctrl+a followed by ctrl+r. This resets everything to their default positions. My expectation is that invisible staves will be reset also, so when I make them visible they will not cause layout problems.
In reply to I don't see a scenario,… by mike320
Sorry for my slow reply and I appreciate the scenarios you provided.
Now I've accepted that, at least for the "select all"/ctrl+a command, it's indeed useful to also perform actions on hidden staves, which has been explained by your comments.
However, all the scenarios you talked about seem to be global changes which affect the whole score.
What about the following scenario, which concerns local modification?
Consider there are 4 adjacent staves: A, B, C and D. And B is invisible. When the user selects from A to C, does he want to make elements in B affected? Maybe he just wants to select the 2 staves(A and C, and they are adjacent now) and adjusts some notes? This seems to be different from selecting all.
In reply to Sorry for my slow reply and… by songchao
That's a good point, but here I'd say it's 50/50 at best as to what the expected behavior would be. For me, by far the most common case for invisible staves is to hear something on playback that I don't want to see on the score - like a trill or chord symbol all written out. Chances are the visible staff below has the written out version. if I delete or transpose the content on the visible staff, I probably want the same for the invisible staff above. Of course, that won't happen today if I literally select just the visible staff and not a range. So one way or another, there will be cases where you need to make the invisible staff visible again to work with it. But I still feel the current scheme is better than the alternative for most use cases.
In reply to That's a good point, but… by Marc Sabatella
OK, I think I understand better now. If the contents of invisible staffs are chords or something else related to the visible staff, then they are probably good to be modified together.
I originally thought invisible staffs were just used to contain some temporarily unused or backup contents and irrelevant to visible staffs, which is probably not the case for other users.
I'm mostly curious as to what triggered your question.
If it is solely triggered by actions applied to hidden staves can lead to bugs, then I personally feel that fixing the resulting bug is likely worth it, rather than disallowing the action. The "crude crutch" solution would be: unhide the staff, apply the action, hide the staff. Which, to be clear, is a very bad workaround for the bug IMO.
Special casing invisible staves requires a decent amount of rework of the code (+ future maintenance of it); I'm wondering if it's worth it and whether the change in behavior won't actually trigger more bug/expectancy reports than the ones we currently have because we do perform actions on hidden staves.
It almost seems like you're looking for a way to lock a stave (whatever that may entail) and are musing that hiding it might perhaps be interpreted as such; I'm currently not convinced for the necessity of either, but you're free to make your arguments and make me reconsider my point of view :-)
In reply to I'm mostly curious as to… by jeetee
Well... it's originally the 2 issues that triggered my question.
At first I just wanted to fix the bug, then I found this behaviour of including hidden staves when selecting was really strange to me. After I asked for its correctness in Telegram, it seemed to be talked as a controversial issue. So I asked here to see if there could be some possible improvement, just out of interest😄 (in fact, I'm not likely to have time to make corresponding code changes currently, even if we approve of special casing invisible staves)
then I personally feel that fixing the resulting bug is likely worth it, rather than disallowing the action
Indeed, I agree that directly fixing the bug would be simpler and more acceptable for now, which is what I plan to do later.
It almost seems like you're looking for a way to lock a stave...
Yes, I really thought the invisible staff could be interpreted as locked. But I'm willing to change my mind if "we do need to perform actions on hidden staves", as you said.
AFAIC, I don't like the behavior of selecting invisible staves. But now it seems that other people are mostly comfortable with it.
In reply to Well... it's merely the 2… by songchao
You currently have two opinions besides your own. Hopefully there will be others as well. FYI, if there were a flood of people agreeing with you I would not be out of joint if I were in a minority that didn't understand why the change needed to be made. It is good to discuss things like this and that's why I encouraged you to start the discussion.
In reply to You currently have two… by mike320
Yeah, I would also be OK if I were in a minority that wanted to make the change :)
I understand that there might indeed be cases where you don't want the invisible staves affected by an action, but given that this is not the purpose of invisible staves, I feel that's really the minority of cases. Transposition, deleting, running paste half/double duration, reset - these are all pretty common operations for which I think including invisible staves makes sense.
Now, the idea that one might want to exclude invisible staves for some operations is interesting. I could imagine a checkbox for this being added to the Selection Filter.
In reply to I understand that there… by Marc Sabatella
a checkbox for this being added to the Selection Filter
Good idea Marc.
In reply to I understand that there… by Marc Sabatella
The checkbox idea seems exciting to me, too