view-spec-dsl.hpp File Reference

Go to the source code of this file.

Description

A framework for configuration of view access and allocation patterns.

Component views are building blocks of the Lumiera UI, and may, depending on their type, be instantiated or allocated according to specific rules and patterns. And these might vary in accordance to the desired working style. To give a typical example, at times it might be mandatory to use a single, external output for all kind of media playback, while other users prefer the classical editing application layout with two media viewers side by side. And yet another working style would be to use a stack of media viewers allocated on demand in MRU-fashion.

To specify those standard behaviour patterns, we provide a small internal DSL to spell out the default configuration in a (hopefully) self explanatory way.

Todo:

as of 9/2017, we confirm the intention to open this configuration DSL for some kind of user provided flexible configuration of screen layouts eventually; yet right now, only the foundation for this flexible configuration is provided while the defaults are to be compiled into the UI as hard wired constants.

Allocation of UI component views

Within this context, Allocation means...

• to constitute the desired element's identity
• to consider multiplicity and possibly retrieve an existing instance
• to determine the hosting location
• possibly to instantiate and register a new instance
• and finally to configure that instance for the desired role

View access

The global access point to component views is the ViewLocator within InteractionDirector, which exposes a generic access- and management API to

• get (possibly create) some view of given type
• get (possibly create) a view with specific identity
• destroy a specific view Together these operations expose a strictly typed direct reference to the respective view component and thus allow to manage them like child objects. Operating on top of these primitive operations, the configuration of view access patterns creates a flexible binding layer, which isolates the users of component views (typically other parts of the UI) from the actual mechanics of locating. While the client just retrieves a view instance, a dedicated allocation logic ensures this view instance is actually placed at the desired place within the UI, and manages active view instances.

Configuration DSL

Access to component views typically happens through the ViewLocator provided by the InteractionDirector. The implementation of view access in turn redirects access through the configured patterns.

• at definition site, explicit specialisations are given for the relevant types of component view
• each of those general view configurations
  • defines the multiplicity allowed for this kind of view
  • defines how to locate this view ... and that location definition is given as a list of alternatives in order of precedence. That is, the system tries each pattern of location and uses the first one applicable.

Actually, the definitions and tokens used within the configuration DSL are implemented as functors. At implementation level, the basic specification tokens are bound to the corresponding operations within ViewLocator and PanelLocator. Thus, the "value" retrieved from the configuration is actually a functor, which provides the desired behaviour pattern

• the locate spec is evaluated to yield user interface coordinates representing the desired location of the view
• the allocate spec is then evaluated as a second step, while providing the coordinates from first step. This results in calling a dedicated view allocator to create a new view or re-use an existing one as appropriate.

Note

the actual binding for the DSL tokens can be found in the ViewLocator implementation

See also

ViewSpecDSL_test

id-scheme.hpp

view-locator.hpp

view-locator.cpp

interaction-director.hpp

Definition in file view-spec-dsl.hpp.

#include "lib/error.hpp"
#include "lib/symbol.hpp"
#include "lib/depend.hpp"
#include "lib/meta/function.hpp"
#include "lib/meta/tuple-helper.hpp"
#include "lib/meta/function-closure.hpp"
#include "stage/interact/ui-location-solver.hpp"
#include "stage/interact/ui-coord.hpp"
#include <functional>
#include <utility>
#include <string>

Classes
class	AllocSpec< ARGS >
	A specification to describe the strategy for allocating (placing, retrieving) a component view. More...
struct	Descriptor< V >
	Generic Component View descriptors. More...
class	LocatorSpec< depth >
	A specification to describe the desired location of a component view within the Lumiera UI. More...

Typedefs
using	Allocator = std::function< UICoord(UICoord)>
	Allocator is a functor to resolve a given, desired location of a view within the UI, resulting in creation or allocation of the view – which happens as side-effect. The result of this invocation are the UI coordinates of an existing or newly created view.
using	Locator = std::function< UICoord(Literal)>
	Locator is a functor to resolve to a topological location in the UI-tree. More...
using	ViewSpec = LocatorSpec< UIC_VIEW >
	A specification to describe the desired location of a component view within the Lumiera UI. More...

Functions
template<class VIEW >
Descriptor< VIEW > &	viewSpec ()
	Access point: Factory for "view specs". More...

Namespaces
	stage
	Lumiera GTK UI implementation root.
	stage::idi
	generic definitions for element ID and access.
	stage::interact
	UI interaction control.

---

Class Documentation

stage::idi::Descriptor

struct stage::idi::Descriptor

Collaboration diagram for Descriptor< V >: