display-manager.hpp File Reference

Go to the source code of this file.

Description

Abstraction: service for the widgets to translate themselves into screen layout.

Architecture

We strive to break up the whole process of controlling the layout into several local concerns, each of which can be made self contained. The backbone is formed by a recursive collaboration between two abstractions (interfaces)

• the building blocks of the timeline expose the interface timeline::Element
• the global timeline widget implements a timeline::LayoutManager interface

Display evaluation pass

Whenever the layout of timeline contents has to be (re)established, we trigger a recursive evaluation pass, which in fact is a tree walk. The layout manager maintains a DisplayEvaluation record, which is passed to the involved layout elements within the timeline. Each element in turn has the liability to walk its children and recursively initiate a nested evaluation. During that pass, we are able to transport and aggregate information necessary to give each element the adequate required amount of screen real estate.

Abstracted relative coordinate system

When treated naively, there would be serious risk for the DisplayManager to turn into some kind of GUI God class, which hooks deep into the innards of various widgets to effect a coordinated UI response. To defeat this threat, we are rather reluctant to expose the DisplayManager itself. Rather, essential functionality is decomposed into self contained sub interfaces, each targeted at some specific aspect of drawing or layout management. Especially, there is the system of interwoven DisplayHook / CanvasHook incantations.

Widgets are wrapped and decorated as ViewHooked, which is tightly linked to the corresponding ViewHook interface. This collaboration allows to attach or "hook" the widget into some abstracted display and layout management framework, without exposing the internals of said layout management to the widget, allowing just do detach or to re-hook those widgets in a different order. And in a similar vein, the sub-interfaces CanvasHooked / CanvasHook expand the same principle to an attachment at some coordinate point (x,y). In fact, CanvasHook allows to introduce a relative coordinate system, without the necessity for the actual widgets and their managing entities to be aware of these coordinate adjustments. This patterning serves as foundation for implementing UI structures recursively, leading to code based on local structural relations, which hopefully is easier to understand and maintain and extend in the long run.

Avoiding the double-indirect calls?

In theory, it would be possible to avoid the double forwarding indirect calls in all the operations of RelativeCanvasHook: We'd have to provide a concrete mix-in to be used already within body-canvas-widget.cpp, and this mixin would hold a direct reference to the embedded Gtk::Layout and provide an additional API to adjust the offset. However, the savings through such an implementation scheme would be dwarfed by the effort for actually rendering a widget.

Todo:

as of 10/2018 timeline display in the UI is rebuilt to match the architecture

WIP-WIP-WIP - drafting the DisplayEvaluation as of 3/2020

WIP as of 1/2021 about to build a first preliminary Clip representation

Definition in file display-manager.hpp.

#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "stage/model/view-hook.hpp"
#include "stage/model/canvas-hook.hpp"
#include "lib/util.hpp"
#include <sigc++/signal.h>

Classes
class	DisplayManager
	Interface for coordination of the overall timeline display. More...
class	DisplayViewHooks
	Interface: a compound of anchoring facilities. More...
struct	PixSpan

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