Lumiera 2018 Development Report

The design of the Lumiera UI is of such fundamental importance that much effort and care has been devoted to its requirements and design. The UI must support the user workflow and Lumiera aims to provide a high-quality professional non-linear video editor. The nature of such a workflow is itself intricate and complex. Hence, the care and attention.

After consulting professional video editors it has become apparent that traditional point-and-click methodology will not rise to the challenge. An entirely new UI concept is required.

One aspect under scrutiny is the diversity of functionality various widgets on a typical Lumiera screen will have to support to provide a user with the plethora of functionality at their finger tips. To support this, a new layer has been conceptually added between the UI widgets and the user interaction. Typically, a simple widget can be on or off. The user simply “clicks” the mouse to interact. More complex interaction is required to trim or roll or slide a clip. We can think of yet more complex interactions, such as picking a specific transition and applying it informally to a select number of junctions in a sequence.

We generalise user interaction with widgets as a gesture, “clicking a mouse” being one simple instance of an interaction. Yet, in general, a gesture is comparable to a sentence in common spoken language, in as much as there is always a predication, a subject and possibly some further objects as targets. Once the UI detects that a gesture has completed, a complex series of events can occur, depending on the gesture received. To add complexity to diversity, a single gesture can involve a number of different widgets: a number of gestures can involve a single or several widgets.

To describe and manage user interactions at a higher level, a topological coordinate system has been devised. It complements the usual addressing within user interfaces, which is based on pixel coordinates and direct references to widget implementation objects. Our new topological UI-Coordinates allows us to address a location within the structure of the user interface, e.g. within window 1, in panel A, view B, tab C. This is the basis of supporting a more systematic navigation of focus within the UI. Moreover, such coordinates provides the ability to define rules of, for example, where to place a new view, or where to show a property panel.

Apart from work done on implementing a vertical slice from the top-level UI down to the backend and back up to the front-end again, work was carried out on a few areas which had already been discussed over the previous Spring.

Top-level components were arranged on the UI layer in a manner that was tending to become diffuse and losing an obvious structure. Components have been reorganised to optimise clear structure, more coherence and improve sustainability.

Various issues plagued accessing components and the order of initialisation required scrutiny. These have been rectified. The Lumiera UI, which is itself a plug-in and dynamically loaded at runtime, can now be loaded and shutdown without any difficulties.

Component dependency is a major software concern. We strive, as a fundamental software practice, to decouple software components so that components do not depend on one another. However, to implement even the simplest of tasks without over complex code, we create dependencies.

The centre of much debate currently is how one component can access the dependencies of another component? There are several proposals to dependency injection which in parts were hotly debated during the past decade within the software community.
[A seminal article on the topic was provided by Martin Fowler in 2004: »Inversion of Control Containers and the Dependency Injection pattern«.]

A complex project like Lumiera is also confronted with the ordeal and some effort was devoted to implement a solution to this and is provided in this ticket.

To support the improved structure in the UI backbone, the current helpers in Lumiera were reworked and improved to facilitate component wiring. A service can now be exposed so that it can be picked up at another site that is not directly connected to the site at which the service was exposed.

Components are now guarded during initialisation using std::atomic from the recent standard C++ improvements.

→ Details.

Various components have been integrated together so that we can now issue a command over the UI bus which is then packaged into a message, received onto a queue and then dispatched into a different processing thread within the session sub-system. As a proof of concept, the dummy test command sends a status update back into the UI, which is transmitted back over the UI bus to effect a status change on a given widget. This test setup represents the first integration of various fundamental low-level components to form a complete collaboration cycle with an action triggered from the UI and a response generated within the session and pushed back into the UI asynchronously.

This development step is an important milestone in the development process.