view-locator.hpp File Reference

Go to the source code of this file.

Description

Access and allocation of UI component views.

Within the Lumiera UI, a component view is a building block to deal with some component of relevance to »the model«. As such, all component views exhibit some distinctive traits:

• they conform to a built-in fixed list of view types, each of which is unique and dedicated to a very specific purpose: Timeline, Viewer, (Asset)*Bin*, Infobox, Playcontrol,...
• each component view has a distinguishable identity and is connected to and addressable through the UI-Bus.
• it can be hosted only at a dedicated location within one or several specific docking panels.
• multiplicity (one, one per window, many) depends on the type of view and needs to be managed.
• such a view is not just _created – rather it needs to be allocated

LocationQuery and the View-Spec DSL

Implementation wise, there is a tight connection between the ViewLocator service, the Navigator service and the configuration how and where to create standard view elements (the "View-Spec DSL"). Several interactions require the UI to access or create some specific view widget by side-effect. And the logic how and where to create views can be quite intricate and is closely related to global, overarching topics of interaction design. Lumiera thus relies on a framework for default configuration, and a matching mechanism to determine the location and creation modes of such views. This matching mechanism in turn requires an abstracted view on the UI seen as a topological tree structure of relevant entities (windows, panels, views,...) – which is basically the service provided by the Navigator; yet this Navigator service can be abstracted into the stage::interact::LocationQuery API, and this abstraction allows to keep all the intricacies of navigating concrete UI widgets confined within the implementation of the Navigator service.

Todo:

WIP 6/2018 half finished draft ////////////////////////////////////////////////////////////TICKET #1104

Remarks

the performance of such an view location and access step is not considered a priority. As it's implemented right now, the access several times repeats the same drill-down into the UI widget structure. This was deemed acceptable, since we assume views will be located only occasionally, while further UI interactions will use either direct wiring or messages via the UI-Bus. On the other hand, the flexibility in the configuration seems important and the complexities generated thereby can be a maintenance burden. Which means, a clear typed interface within the DSL is more important than burning some more CPU cycles.

See also

interaction-director.hpp

panel-locator.hpp

Definition in file view-locator.hpp.

#include "lib/depend-inject.hpp"
#include "stage/id-scheme.hpp"
#include "stage/interact/view-spec-dsl.hpp"
#include "stage/model/element-access.hpp"
#include "lib/idi/genfunc.hpp"
#include "lib/symbol.hpp"
#include "lib/nocopy.hpp"
#include <functional>
#include <string>
#include <memory>

Classes
class	ViewLocator
	Access or allocate a UI component view. More...

Namespaces
	stage
	Lumiera GTK UI implementation root.
	stage::ctrl
	Backbone of the Lumiera GTK UI.
	stage::interact
	UI interaction control.