01 June 2014

This past week I focused on refactoring the current selection code. I have also started writing code for the selection window.

Shift select note creates a range selection with a note and a time signature

While reviewing my previous solution, I came to a realization that it is not the best. It involved ending drawing of a selection when the element was an end bar or a time signature and the element was the last in the selection. The two elements should not be in the selection in the first place. The problem could be solved earlier, when the actual selection is created. If the correct end segment is picked, the problem would be solved. A range selection contains all elements from a range [start,end). So we need to set the end segment to the segment right after the last segment we want to include.

In most of the code, we have used the following method to get the end segment:


This worked fine for notes in start and middle of a measure. For notes at the end, this returned notes in the next measure. That is why the selection included the end bar, and the time signature.

The other option was calling the following method:

tick2segment(cr.tick() + cr.actualTicks())

This method returns the segment at the current tick. There is one problem thought. This method first looks for a measure that contains the tick, and later returns the first segment that contains the tick. Both an end bar and a time signature do not have a duration, so the tick for end bar, time sig, and the chordrest in the next measure was the same. Since the tick2segment method works by looking at the measure first, it returned the chordrest in the next method.

For this I have created a new method:

nextSegmentAfterCR(ChordRest* cr)

It returns the segment right after the chordrest taking into account the duration of a chordrest, so it works correctly for notes with more than one voice.

Selection refactor

In the first refactor PR , I have changed all checks for selection type with isType methods. This makes the code cleaner, and if we ever want to change the underlying enum, we can change that in one place. The other thing I have done was to divide the select method in score.cpp into 3 methods. Now there is a separate method for single, add and range selection. This PR has already been merged.

The second PR involves refactoring the range method from the previous refactor. The range method involves extending the selection. There were multiple places where the same code was repeated. I have isolated and moved the code into a new method extendSelection. This method does all the necessary checks and changes the start or end segment accordingly.

Selection Window

I have thought about the look of the selection window. I have decided to mimic the pallete box. It is normally docked on the left side, but can be moved around. Sibelius has a similar solution. So far I have added code that creates a displays the window. Not sure how the windows should look like. I was thinking about displaying a list of checkboxes. If you have any other suggestion, let me know over IRC or mail.


Unfortunately, since saturday evening there is some travis error, that makes the build fail.

It fails on the with the following errors:

$ artifacts -v || curl -sL https://raw.githubusercontent.com/meatballhat/artifacts/master/install | bash

/home/travis/build.sh: line 320: artifacts: command not found /home/travis/bin/artifacts: line 1: syntax error near unexpected token newline /home/travis/bin/artifacts: line 1: <?xml version="1.0" encoding="UTF-8"?>

I hope this issue will be resolved soon, so we can continue to merge new PRs.

Tasks in the upcoming week

Tommorow I plan to finish up the selection window along with all the components. This will include adding checkboxes, saving position info and adding a shortcut. During the week I will continue refactoring the selection code and solve any reported issues with selections. I will also add new tests, invoving selection transitions.