Lomse library. API documentation
0.30.0
|
#include <lomse_half_page_view.h>
HalfPageView is a GraphicView for rendering scores.
This view has a double behaviour. In normal mode (no playback) it behaves as SinglePageView, that is the score is rendered on a single page as high as necessary to contain all the score (e.g., an HTML page having a body of fixed size).
But when 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 mode.
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 the view is in split mode (during playback) all settings 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.