Highlighting and range selection
This week I have fixed a few bugs involving selections and highlighting. I’m already feeling more confident with the selections code.
This feature request involved the highlighting of elements that are linked to notes. After discussing this feature on IRC, I have implemented this for the range selection. As of now accidentals, steams, beams are selected along with the notes. Ties and slurs are included in the selection if both end elements belong to the selection.
While testing the highlighting of spanners, I have noticed that ties get copied even if only the first element is selected. It seemed counterintuitive so, I have changed the code to only include spanners which have both end elements are in the selection.
When testing the transition between the list and range selection, I have noticed the following inconsistency: If two elements are selected in a list selection, and a user tries to extend the selection (by using shift click) to include another measure nothing happens. If the user tries to extend it by a chord rest, the current selection gets removed, a new range box is created containing the new element, but the element is not highlighted. The picture below illustrates the issue when range selecting a note:
After talking this through on IRC, the expected result is to remove the current selection and range select the clicked element. The resulting selection should have the elements highlighted. I have fixed both bugs. As of now, shift clicking a measure or a chordrest always range selects it.
While testing the range behavior I have noticed that a range selection consiting of the last note in a bar followed by a time signature change results in both the note and the time signature to be selected. The picture below shows the behavior after shift clicking the note.
This is a bug because shift selecting a note should only range select the chord rest that the note belongs to. The reason for this bug was that a range selection ends with one element after the selection. Since the last element was the chord rest in the next bar, musescore highlighted the time signature and stretched the selection to include the barline and the time signature. I have fixed both of these issues, with the following result :
Sound on completion of build
When changing the selection header file or when switching to a different branch, the build takes quite a while. I have added a command that plays a coin sound from mario after compiling. If anybody wants to try this, you can try the following steps:
- Go to Project -> Add Build Step -> Custom Process Step
- Add your sound player capable of playback from the command line. I have used aplay.
- In the parameters textbox add the path to your sound, and follow it with 2>/dev/null. (This will avoid showing errors by QtCreator)
That’s it, from now on you will be informed of a finished compilation with a sound!
Tasks in the upcoming week
I will continue refactoring the selection code. My goal is to remove all calls to setState, so only functions such as setRange, deselectAll etc will change the state of the selection. This will allow further division of the selections. Ideally there will be 3 selection classes along with a manager that will switch between them. I have already started work on this, but decided to refactor the select method first so it will be easier to finish. The selection refactor branch is available here.
I also plan to implement a tick method for more elements, so that we will be able to sort the selection element list. The plan is to add a new feature: when shift selecting a new element while having a list selection consisting of more than one element, a new range selection will be created spanning from the earliest element tick to the newest. At the end of the week, if there will be time, I will look into creating a new window with selection options.