Lumiera 2017 Development Report

The obvious first step in this effort was to institute the counterpart to which UI-Elements might talk. Over time, a lot of code has been written to define structures within the Proc-Layer and »High-Level Model« (session model), including a complete framework for defining and handling of commands. Yet all of this code used to be passive, waiting to be called and activated by “someone”. So the endeavour of building a UI connection helped to link all these existing parts together into a coherent Subsystem, which is now actively started when launching the application. The key element for this achievement was finally to build the ProcDispatcher, which performs a dedicated thread to execute incoming commands one by one, and which cares to invoke the Builder regularly.

As UI-Elements will start binding to actions within the session, we needed to organise the definition and lookup of Proc-Layer commands. Building on top of the aforementioned command framework, concrete actions can now be defined within a library of small-ish functions at one central location. In accordance with the message driven architecture we’re aiming at, the actual action binding within the UI widget now issues a message on the UI-Bus, which causes the corresponding command functor to be retrieved from a registry and enqueued with the ProcDispatcher.

Any action induced by user interaction can be considered to cause an ongoing chain of reactions, with integration of feedback results into the UI display finally to close the circle. While this is commonplace, the important twist to note is the fact that this chain of reaction soon submerges into background activity, relieving the UI to be ready for the next interaction.

The execution of Proc-Layer commands thus requires a counterpart: a service offered by the UI to receive any changes effected by the command. Building such a service especially involved the integration of the diff framework created during last year, which allows to publish structural changes without tight coupling between producer and receiver. In line with the envisioned architecture, the actual diff application was realised as a callback, which is dispatched into the UI event thread and thus “pulled” by the receiving widget, prompted by a tiny notification message passed over the UI-Bus.

While this current work at the UI can be described as pragmatic, this is the right moment to consider as to where our long term vision interferes with the commonplace way of dealing with UI construction. Since quite some time, there is a “background thread” of discussion ongoing within the Lumiera project, regarding the direction we see for further evolution of human-computer interface and to what extent we actually want to push in that direction. Just recently, an offspring of these discussions has crystallised into a set of terms and definitions we label as Interaction Control. Following this route would require us to intersperse a secondary yet overarching control system in between the structure and “mechanics” offered by the usual UI toolkit set but above our actual widgets. On the long run, such an interspersed structure will allow us to “pull some strings” — without actively interfering with or even opposing the way usual UI toolkit sets happen to deal with UI programming.

In line with this reasoning, on reshaping the internal UI structure, we made allowance for the anchor points such an extended control structure might hinge upon eventually. Most notably, we introduced the notion of topological UI-Coordinates to refer to some component within the UI implementation, instead of navigating the widget hierarchy directly on implementation level. As immediate benefit, this allows us to store and configure the place where some new view will be instantiated, instead of intermingling this decision with low-level widget handling code.