The new emerging NLE for GNU/Linux

Coding: Upgrades

Updates to language and project support libraries, detailed in the last report, 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” (Version 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 libBoost 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 (lib 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.