ui-bus.hpp File Reference

Go to the source code of this file.

Description

Under construction: the top level UI controller.

The Lumiera GTK GUI is built around a generic backbone structure known as UI-Bus. This is a messaging system and taps into any widget of more than local relevance. To that end, any globally relevant (custom) widget, and all secondary controllers inherit from the stage::model::Tangible base. The top-level stage::UiBus element is a front-end and framework component managed by the GTK-main.

Warning

as of 12/2016, this is still totally a mess. This will remain the one-and-only master controller of the UI, but I am determined to change the architecture and implementation technique altogether. For the time being, we keep the controller::Controller in place, as written by Joel Holdsworth, while building the new UI-Bus frontend to take on this central role eventually.

Rationale

The UI-Bus acts as a mediating backbone, impersonating the role of the Model and the Controller in the MVC-Pattern in common UI architecture.

The MVC-Pattern as such is fine, and probably the best we know for construction of user interfaces. But it doesn't scale well towards the integration into a larger and more structured system. There is a tension between the Controller in the UI and other parts of an application, which as well need to be in control. And, even more important, there is a tension between the demands of UI elements for support by a model, and the demands to be placed on a core domain model of a large scale application. This tension is resolved by enacting these roles while transforming the requests and demands into Messages.

Through this architectural decision, we introduce the distinction between the local, tangible UI "mechanics" on one side, and the common, generic interaction patterns on the other side. The former, the mere "mechanics" of the UI shall be kept simple and reduced to immediate feedback and reactions to operating some interface controls. Any actual operations and actions relevant to the application as a whole, are to be sent as messages into the UI-Bus. The interface code can assume some "core services" to be available somewhere; these core services will receive the messages, act on them and respond asynchronously.

Bus interactions

The UI-Bus has a star shaped topology, with a central "bus master" hub, the NexusNexus"", which maintains a routing table. Attachment and detachment of elements can be managed automatically, since all of the UI-Bus operations perform within the UI event thread.

We distinguish between up-link messages, directed towards some central service (presentation state management or command invocation) and down-link messages, directed towards individual elements. The interactions at the bus are closely interrelated with the elementary UI-Element operations.

• act: send a GenNode representing the action
  • the ID is either a globally registered command-ID or an explicitly opened command instance ID.
  • the payload is a Record<GenNode> holding the actual command arguments
  • on reception, an instance (anonymous clone copy) of the command is created, bound with the arguments and handed over to the SteamDispatcher to be enqueued for execution.
• note: send a [GenNode] representing the state mark; some (abstracted) presentation state manager is expected to listen to these messages, possibly recording state to be restored later. The contents of the state mark message are implementation defined; knowledge about these is shared between individual widget implementations and (partially, to some degree) the presentation state manager.
• mark: down-link communication to feed back state updates or to replay previously recorded state marks.

Note

The mark verb can also be used as an (future) extension point to send generic messages – possibly even to broadcast them to interested subjects, which have been registered with the Nexus as targeted receivers...

Warning

deliberately the UI-Bus is not threadsafe. Only [Tangible] elements performing in the UI-event thread are allowed to talk to the bus.

See also

bus-controller.hpp

bus-term.hpp

ctrl/nexus.hpp

ctrl/core-service.hpp

Todo:

as of 1/2015, this header needs to be reshaped ////////////////////TICKET #959

Definition in file ui-bus.hpp.

#include "stage/gtk-base.hpp"
#include "stage/ctrl/playback-controller.hpp"
#include "lib/nocopy.hpp"
#include <memory>

Classes
class	Controller
class	UiBus
	Backbone of the Lumiera GTK GUI. More...

Namespaces
	stage
	Lumiera GTK UI implementation root.
	stage::ctrl
	Backbone of the Lumiera GTK UI.
	stage::model
	The Lumiera GTK-GUI uses a thin proxy layer data model on top of the actual "high-level-model", which lives in the Steam-Layer below.