display-evaluation.hpp File Reference

Go to the source code of this file.

Description

A collaboration to establish a globally coherent timeline display layout.

Whenever the layout of timeline contents has to be (re)established, a recursive evaluation pass is triggered, which in fact is a tree walk. As a foundation, we assume that GTK has provided each of the actual widgets with a screen space allocation sufficient to render the content known thus far. At this point, we need to traverse the whole timeline structure, collect size and allocation information and create additional screen space requests if necessary. Generally speaking, this recursive process can not be entirely successful at first pass; typically additional space requirements are discovered and propagated as message to GTK, and so the DisplayEvaluation can be expected to be re-triggered soon thereafter.

Specification

The basic goal is to establish a coherent vertical space allocation for all tracks within the timeline (while, to the contrary, the horizontal extension is a fixed requirement and can be derived from the covered time span as translated by a zoom factor). This can be achieved by

• collecting the vertical content extension within each track individually
• buildup of a timeline::TrackProfile to accommodate those requirements and all decorations
• adjustment of the TrackHeadWidget extensions to match the allocated track body space precisely.

Evaluation structure

This is an intricate collaboration of closely related elements; however, each of the aforementioned tasks is defined such as to operate in a self-confined way on some part of the timeline. All the collaborating elements implement a common invocation interface timeline::LayoutElement, which allows to pass on the DisplayEvaluation itself by reference, recursively. To make the overall process work, moreover we establish a Requirement to pass on this invocation strictly in layout order – which implies a recursive depth-first invocation proceeding top-down and from left to right. It is each LayoutElement's liability to recurse appropriately in order to make this happen.

Evaluation state and phases

The DisplayEvaluation works by direct (side)effect within the invoked elements, eventually leading to some of the embedded GTK widgets being resized – which typically will re-trigger our custom drawing code and consequently the DisplayEvaluation at a later time point in UI event processing. So the evaluation is triggered repeatedly, until the layout is globally balanced and no further resizing is necessary. The evaluation itself is carried out in two phases: first we collect data and establish the layout requirements, then, in a second pass, we finalise and round up the layout. Each phase calls its own set of callback functions, and always in »layout order« (top-down and from left to right).

Todo:

WIP-WIP-WIP as of 3/2020

Definition in file display-evaluation.hpp.

#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include <vector>

Classes
class	DisplayEvaluation
	Visitor and state holder for a collaborative layout adjustment pass. More...
class	LayoutElement

Namespaces
	stage
	Lumiera GTK UI implementation root.
	stage::timeline
	The timeline display and editing operations.