Make elements not selectable
I want to start a new discussion on how many sense it would make to have elements not selectable. The main use case would be in the new excerptsdialog in order to only select the visible voices. I can't think of another use case, but in this specific case I would say, this might be a good idea.
My problem is, that it currently haven't understand where in the code an Element is selected and what the selectable attribute of any element is actually doing or if it doesn't have an impact when it's changed in the debugger.
There are some problems which may be caused if we make an element option as the invisible attribute, but it would be the only way to use the current implementation with linked staffs.
The question is which problems may occur if we have an ability to make elements not selectable. In every case we have to be sure the user has no ability to manually change this.
Any other thoughts on this and maybe some hints where I should implement this?
Comments
I don't understand the link between voice and elements not being selectable. Why do you want to make elements non selectable exactly and which element in particular?
In reply to I don't understand the link by [DELETED] 5
Look at this example:
We have an instrument with two voices in the score and you want a single excerpt for every voice. So what you do is, you're creating two excerpts for every voice and make one voice invisible in every part. So if you have an invisible voice in a part you shouldn't be able to select this voice. I think this is the basic principle of Musescore, WYSIWYG. So in my opinion it would be the best to have this voices invisible AND non selectable.
To the question of which elements I'm thinking. Most important would be to have non selectable noteheads, stems, slurs, ... In fact everything that is connected with a specific voice and has no impact on the other voices. So the dynamics should always be selectable. Is it getting clearer?
In reply to Look at this example: We have by fbrauchle
Not really. In my view, in the part, the voice will not be displayed at all, so non selectable by default because not even present.
In reply to Not really. In my view, in by [DELETED] 5
Okay, I asked in IRC how the selection does work, but didn't get an answer. So am I right, that if we skip every element of the voices we don't want to show while layouting, they are not selectable at all, because they aren't there? I can't find the place in code where the selection of a note is done, because I'm not sure what I'm searching for.
But in general, this would make the whole thing a bit easier.
In reply to Okay, I asked in IRC how the by fbrauchle
Remember, there are several ways of selecting elements, so there are several entry points into the selection code. You can click, use the keyboard, shift+drag, etc.
I'm still not 100% clear on the context here, but if the idea is to have a part in which voice 1 is made invisible and unselectable, why not just use the Selection Filter for that? You could force voice 1 to be excluded by default.
In reply to Remember, there are several by Marc Sabatella
I think using the Selection Filter is a good idea, but if you're accidentally selecting a note or something else from a voice which isn't visible you are able to change this element. Another problem are for example slurs. You want to select slurs from voice two, but not slurs from voice one when you're copying something from a part.
So there are enough problems to deal with and I was thinking if it wouldn't be easier to have an attribute selectable or non-selectable in order to prevent quite dirty solutions. But the whole discussion would be unimportant, if we simply can't select notes which aren't considered while layouting the part.
In reply to Remember, there are several by Marc Sabatella
Without understanding more about how this would work, I can't really say, but even if you don't literally use the selection filter, it still seems like extending that is a good way to go. That is, we *already* check the staus of the filter, using canSelect() and canSelectVoice(), in the places where we should, so it would seem that simply modifying the behavir of those two functions to ignore whichever voice you want in these situations would be an easy solution.
In reply to Without understanding more by Marc Sabatella
My first idea of making the not used voices in a excerpt invisible and non selectable was to add a list which contains the tracks of all voices which should be displayed, so it is always possible to check if the actual element should be visible or not, of course some elements would always be visible as dynamics. Every time you do a relayout of an excerpt it is checked which voices should be layouted and the other are ignored if this is possible or made really invisible (not just grayed out). I'm still not sure if the first possibility I mentioned is a realistic, but I'll test this.
If not I would have added the same test in the canSelect()-method you mentioned, so we would have to gray out the non selectable voices in the selection filter and set them off as default. This is quite an easy solution as you already said, but I could still select single elements by accidental clicking and this seems to be a problem for me, because it can't be handled with the Selection Filter!?
Please correct me if I overlooked something.
In reply to My first idea of making the by fbrauchle
Well, you'd also need to add code to the click-to-select facility to ignore elements that are not supposed to be selectable. MuseScoreView::elementsAt() or ScoreView::elementsNear() would be possible places to start. I think you could just check to see if this is a "suppressed" voice (you probably want to come up with an official term for this) and ignore it if so.
BTW, I have been wanting to fiddle with these functions and/or related ones, maybe we could coordinate this. My idea is to improve click selection to allow you to access elements overlapped by other elements by successively clicking to access the next element in the stack. Perhaps tied to Ctrl+click, perhaps using Alt, not sure yet.