Implement HalfPageView

[cecilios]

Closes #247. This view has a double behaviour:

• In normal mode (no playback) it behaves as SinglePageView: a single page as high as necessary to contain all the score.
• When entered in playback mode, the bitmap to be rendered in the application window is split horizontally in two halves, originating two virtual vertical windows, one at top and the other at bottom. In the top window it is displayed the first score chunk and the second chunk is displayed in the bottom window. When playback enters in the bottom window the top window is updated with the third chunk. Next, when the playback enters again in the top window, the bottom window is updated with the next chunk, and so on.
• When playback is finished (because the end of the score is reached or because the app stops playback  -- but not when playback is paused --) the display returns automatically to SinglePageView.

This view allows to solve the problem page turning and the problem of repetition marks and jumps: when the window being played has a jump to a system not visible in that window, the other window is updated with the next logical system (the one containing the jump destination) instead of with the next system. The behaviour for the user is very simple: when the end of the last system in current window is reached or when user finds a jump to a point that is not displayed in current window, he/she will know that it is necessary to jump to the other half window.

You should note that when the view is split, only full systems are displayed in the sub-windows. This is to avoid doubts about were the music continues, that could appear in cases in which next system is practically fully displayed after current one. It also makes the display more clear.

The view does not enter in split mode in the following cases:

• when window height is smaller than two times the highest system,
• when window width is lower than system width,
• when the score fits completely in the window height, or
• when the document is not only one score

In these cases, playback behaviour will be that of SinglePageView

When the view is in split mode (during playback) all setting for controlling what to display and how are fully controlled by the view. Therefore, the user application should disable all user controls that could invoke methods to do changes, such as scroll position, zoom factor or other. Invoking these methods will not cause crashes but will cause unnecessary interference with what is displayed.

[dmitrio95]

Maybe I am a bit late for this, but there seem to be a memory leak here: jump entries in this list are created in get_measures_jumps() function with LOMSE_NEW but they seem to be never deleted afterwards. To avoid memory leaks here it would be better to explicitly delete them in a loop, or change get_measures_jumps() return type to something like vector<MeasuresJumpsEntry> (vector of values instead of raw pointers) or vector<std::unique_ptr<MeasuresJumpsEntry>> in case there are concerns that filling a vector of values may be slower in this case.

The same applies also to other usages of get_measures_jumps(), although they seem to be only in tests code.

[cecilios]

Maybe I am a bit late for this

Never is late to improve the code and to fix bugs! 😉 Thanks for reporting!

but there seem to be a memory leak here

Yes, you are right. I forget abour deleting the table. Thank you!! I will fix this today.