Talk to the Log

Making an X-Plane plugin “talk” to us is one of the boilerplate tasks when setting up a new plugin project. X-Plane has its own log file, log.txt, which is found in X-Plane’s root folder. The file gets reset every time X-Plane starts, so there’s no need to rotate or trim it from time to time. As a plugin author, we have the choice to either write our own log file, or to jump on X-Plane’s bandwagon and use its logging system for our purposes. While I can see the benefits of having a dedicated logfile for a plugin, personally I prefer to use X-Plane’s built in logging mechanism – there are technical reasons, but mostly it’s a comfort and usability decision: most X-Plane users will immediately think of the central log.txt file when a developer asks them to provide their log file (e.g. when reporting an issue).

CMake Linux Hack

Beginning with its most recent version (3.25 at the time of writing this post), CMake provides the LINUX variable, which I used in my previous post. Of course, developers on Linux tend to use the version of CMake they can install from their distribution’s package manager. On Ubuntu 22.04 LTS that would be 3.22, and even on the most recent Ubuntu version (22.10) we’re at 3.24 — meaning this variable is not available in these CMake versions.

X-Plane Plugin Boilerplate

X-Plane has a well-documented, accessible API, making it relatively easy to write plugins for the simulator. In this post I’m going to demonstrate how a basic plugin boilerplate can look like, and how to build it on different platforms.

Let’s get started with some basics: X-Plane plugins are dynamically linked libraries, which are loaded by X-Plane at runtime. They have to provide an API as defined by the X-Plane SDK, so X-Plane can access the plugin via defined entry points. The API documentation explains all this, and also provides examples for basic and more advanced plugins. For this post I am going to use a very barebone plugin which does nothing except existing in X-Plane.

Reload 2023

More than five years without new content — that’s a new sad record, even for me. Time to change things. While originally this site was set up to run with HubPress, it never really worked up for as well as it promised in the beginning. Working with HubPress was hit and miss — for me it frequently lost its session context, losing some work done. Also it was pretty picky which browser it worked with. And finally, in 2019, HubPress got shut down. The GitHub repo is still around (archived, i.e. read-only), so there’s no hope the pending issues will ever see a fix.

Colours in Django Models

Colours are quite a common property to real world objects. So naturally when building web applications, sooner or later one encounters the need to assign a colour attribute to an object. For Django developers, this usually means adding a models.CharField to their model, ready to capture the colour’s hex code.

Technically this works pretty well, as those hex codes can directly be used in HTML style attributes, embedded SVG drawings, etc. However, setting colour values via text input widget is quite tedious. On the frontend side, various libraries offer quite elaborate solutions for integrating nice colour picking widgets. For the Django admin, there is however a quite simple solution: use HTML 5 color inputs!

Pythonic Distance Conversion

When dealing with distances or lengths, it’s a common problem to convert values between all the different units available out there. Of course, converting itself is a less than complicated simple floating point division or multiplication, depending on how values and conversion factors are stored internally. However, maintaining conversion factors all across a project is a tedious task, and Python has some good means at hand to simplify our life.

GitFlow Groundhog Day

Yes, this is all over again the old discussion about what’s the best branching model for projects using Git as their version control system. I know, there are countless blog posts (e. g. 1, 2, or 3) about that topic out there… yet, I feel most of the discussion is focused on projects with continuous deployment (i. e. mostly web applications), whereas classical desktop software with classical release cycles are rather underrepresented.

First, some thoughts on what I actually need, before creating any new ideas others put already in the bin due to being unfit… When hacking on a desktop software or an operating system (i. e. something that will be deployed on many systems, by many people, without me as developer being aware), it all comes down to releases. People are used to releases, updates etc. being clearly labelled with a semantic version designator. This is no different from what you should do for SAAS web applications — what’s really different here is that for desktop applications, several supported versions can exist in parallel. So for me, a good branching model should