Lumiera 2016 Development Report

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.

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.

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.

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.