Updates to language and project support libraries, detailed in the
gave rise to the need for additional upgrades and clean-up requirements all over the place.
Once again we bumped our development reference platform, this time to Debian/Jessie, currently the »stable«
Debian distribution. While such an upgrade always triggers a host of smallish
problems which need to be investigated and resolved,
it also enables us to use the latest libraries and — particularly relevant for
us — a more up-to-date compiler as our reference compiler.
Consequently, we have established GCC-4.9 as the current project standard
reference compiler providing us with mature C++11 support and enabling us to
switch to C++14 — a minor language upgrade. Moreover, for us developers, this
new language standard comes equipped with a number of enhancements easing our everyday
work on programming. Furthermore, by using the new version of the compiler and
a more mature version of the
Glib library, we were able to rid the code base of a number
of long standing annoying problems; and a few workarounds were also eradicated.
As usual, we completed this round of upgrades by cutting a new “preview release”
Lumiera-0.pre.03), and, in the process, updating the packages,
dependencies in the build system and the documentation.
Coding Framework Improvements
As a follow-up to this work on the platform, Ichthyo engaged on a series of improvements to our coding
framework within the application. In fact, this work was not all done in a single go, rather it was
intermingled with other activities, which are presented elsewhere in this report. For example, the
use of smart-pointers and hash functions were streamlined, replacing most of the
implementations with their equivalents from the standard library, which are now available as part of
the language standard. In a similar vein, our manually crafted tuple type and the associated
meta-programming to deal with function argument lists could be replaced or retro-fitted to rely on
variadic templates, a new language feature crafted for that very purpose. Indeed, in praise of
Lumiera it was always sufficiently flexible as to be able to draw upon modern programming techniques
to improve productivity, even before these features passed through the gates of the language fathers
to become part of the official programming language.
To complement these achievements, methods for diagnostic printing were unified and augmented. Similar to Java’s
toString() method, we are now able to obtain sensible output from any language
entity, including the automatic use of custom defined string conversions, falling back to a clean
human readable rendering of the language type name, based on using a somewhat obscure yet
standardised interface in the compiler.
Getting to Grips with GTK-3
We were very fortunate with the UI design adopted by Joel Holdsworth. The archetecture decided upon
by him placed us in a very good position to confront the future. His reliance on vector graphics
Cairo) for the UI drawing routines has much to be recommended. He did this in anticipation of
the future direction of GTK from which we were able to reap the rich rewards of a, more-or-less,
painless upgrade. Unfortunately, this did have one negative effect: our custom-made timeline widget
became inoperable — the protocol and interaction between widgets and the GTK framework had been changed
by the GTK developers for version 3. This observation spurred Ichthyo to leave half-finished work
at the player-to-engine connection for the time being, and to focus attention on the UI. Obviously,
being no expert, yet familiar with UI programming in similar frameworks, such an endeavour would
require some study and investigation, in order to be able to grasp how a client should use
and extend the GTK framework.
Coding: Architecture Work
As has already being illustrated in the preceding report, we are still confronted with a two-thronged challenge because we would like to employ our advanced concepts from the session model and put these into the actual user interface structures so that the user can reap the rewards. Collaboration between the session core and UI needs to work asynchronously, otherwise the interface will not be “reactive” and would suffer from sluggish behaviour. While the core structures are inherently flexible, it remains a greater challenge to retain this flexibility in shaping and evolving both components and adopt these to provide an adequate workflow. To cope with these demands, we are more inclined to use a message based inter-connection between the various components.
The UI Connection Backbone
It was no small feat to build the UI-Bus in our efforts towards building the UI connection, which is a message-based backbone to channel commands and data between the core and the GUI. However, this did introduce a distinction between local UI mechanics, to be implemented in the conventional manner via widgets, controllers and “signal” connections, and core editing concerns, which now involve sending command messages towards the core, which later responds asynchronously by deploying structure update messages. This required the formulation and definition of a generic UI element and its communication protocol, a means of forming, building and, finally, issuing commands, and a way to express, capture and later replay interface state changes. The heart of this was accomplished by adopting a generic means to express structural data and changes.
The Timeline Display
After indulging in fundamental work on the “Timeline Display”, it recently became apparent that it
was time to address the actual structure of a reshaped timeline display widget. This relies on the
new canvas control which has been available since GTK-3 (
Gtk::Layout), which allows us to
combine custom drawing with embedded widgets placed on top of a scrollable “timeline canvas”. The
new structure is now in the works. This will be entirely recursive, no longer relying on a “shadow
model”, rather on a connection to the UI-Bus.
Collaboration and Exchange of Ideas
Last winter, there was an inspiring conversation and exchange of ideas between Ichthyo and Andrej from OpenCine project, which is related to the Apertus° effort. These new cameras will provide raw sensor data. Obviously, we require a free application to develop raw video stream data, in a way similar to what is known from developing raw digital (still) images. Starting from “how to integrate for example into Lumiera?”, the discussion quickly turned towards requirements to enable integration of raw video processing into any suitable free software, which means how to make a library behave as a “good citizen” and what it means to be a “good citizen” especially with such a challenging and resource hungry task as raw developing of 4K video promises to be. This discussion also helped us to identify the possible workflows to deal with shooting and editing raw video footage:
raw develop in OpenCine and encode into a conventional codec, then continue production with established software
raw develop in OpenCine, import the result as a proxy and produce the final result with batch processing the edit
embed a raw developing library to produce a preview, do all editing non-destructively, then develop on a final render
The consensus was that the first kind of workflow would be the starting point since it allows the whole effort to be bootstrapped with the notoriously limited developer resources in any OpenSource project. However, the second and the third alternatives should be the envisioned workflow, the way we actually want to work and the kind of workflow we are aiming towards.
On a Personal Note
In 2016, Ichthyo had to face serious health concerns, as he was diagnosed with abdominal cancer. As it turned out after surgery, the discovery happened in the nick of time, and prevented the disease from spreading further. While, now, the prognosis is good, this encounter was interpreted as a reminder that life is short, and the possibilities are not endless.