Back to Open Cue Master

Earlier in the year I started a project called Open Cue Master. The purpose of OCM is to be able to stript out cue automations for stage production, such as music and video playlists, sound effects, DMX lighting, script display, and more. I built a pretty powerful tool that was used to control a 2 1/2 hour long dance recital that include 9 additional play and Ballet performance acts. It work without problems, but I haven't done anything with it since June 2022.

I developed it using JavaFX. JavaFX provides great multimedia, animation, UI capabilitites. I integrated FXWeaver for IoC and DI using Spring, which worked very well. It compiled into a single executable JAR that has no problem booting in a system with an istalled JVM. But, I want to be able to share this tool with others and that means going native.

My experiements with the GraalVM have proven that I can generate and execute native Windows and Android applications from JavaFX. However, the FXWeaver with Spring version of OCM doesn't seam to work very well. So, I want to use one of the lighter weight IoC and DI frameworks that work with Gluon.

I also want to experiment with the Gluon package goal. And, in order to that on Windows, I need to install WIX.

1) After downloading Wix 3.1.1 (I don't like this version number), and executing the installer (installer for an installer), I get this terminating message:

2) I followed the instructions at https://stackoverflow.com/questions/43123984/turning-windows-features-on-with-wix-installer to enble .NET 3.5 - No restart required (on Windows 10 - though it keeps pestering me to install Windows 11)

3) I ran the gluon:package goal again only to find that I preceeded it with the clean goal. So I'm running gluonfx:build and gluonfx:link to see if it gets me the exe again (rather than gluonfx:nativerun) - link generates the EXE

4) Running the gluonfx:package goal generates a 22M Windows Installer. There appear to be some configurations for the installer that I can set (need to read the documentation). - The installer works. - as does the uninstaller.

Can I reduce the EXE size by including a module-info file? Currently, it's 64M. I'll add a module-infor.java file and find out.

Using the Netbeans Java Module Info file creator, it scans the current source and creates one. Now to test it's effectiveness.  (it doesn't exactly create a perfect module-info). It also didn't reduce the size of the executable.

I using the occassion of OCM to experiment with these native JavaFX capabilities while I figure out what the EFB and EFIS applications look like.

I do have a Mac and iOS devices to experiement with as well and will eventually get to them.

For now, I can confirm generating a Windows installer works. The Gluon Maven tools (when the GraalVM has been properly installed following the GrallVM documentation and the Gluon docs) is working as advertised.

Kicking It Off

I've been researching both "sources of data" and "platform technologies" in order to anchor a starting point. I've found most of the data I'm interested in and will get into more detail in later posts. The data comes in what I'm categorizing as either easily consumable or highly specialized forms that require additional technologies to work with.

I'm focusing now on the platform side of this effort. A "platform" is the type of device and operating system on which applications execute. For example, an Android tablet, an Apple iPad, and a Windows laptop are platform types.

Typically, applications are platform specific (i.e. they execute only one platform type). Popular, large market applications may have versions that execute on multiple platforms (e.g. Microsoft Office, Garmin Pilot) but are often written in different programming languages due to platform specific tooling. Consequently, cross-platform development technologies do exist to simplify application development, but often fall short in the area of platform-specific features.

For my purpose, I'd like to develop aviation tools for as many platforms as possible without the need to utilize different platform specific tools. In particular, I'm interested in developing native applications on the following platforms:

• Android phones and tablets
• Apple iOS iPhone and iPad
• ARM processors (i.e. Raspberry Pi, BeagleBone, etc.)
• Windows PC
• MacOS

As I like to name applications before I get started (and usually change it later), I've been thinking about a theme. My theme is to use the initials from Mattie Tech (MT) and combining them with the application function. For example, mtFC - Flight Computer would be used for the E6B mobile app, mtFB - Flight Bag for navigation and planning, mtWx - Weather for weather data (also available in mtFB), and mtFIS - Flight Information System for the built-in EFIS.

First Post on EFE

Hi there! Welcome to Electronic Flying Experience (EFE). In case you're wondering, this is not a blog about flight simulators, though that topic may come up. This blog about building gadgets for pilots, commonly referred to as an Electronic Flight Bag (EFB), and the more involved Electronic Flight Information System (EFIS).

Being a Software Engineer, Micro-electronic Engineer, pilot, and experimental aircraft builder, I'm fascinated by the thought of creating an EFIS and all that goes into it. Fortunately for most aircraft builders, EFIS avionics are plentiful. Unfortunately for most aircraft builders, avionics constitute up to one-third of the cost of an airplane.

This blog isn't about saving money. It's not necessarily about building a working EFIS, though that would ultimately be an objective. It's about capturing the details of researching data sources and software engineering through exploratory work that can form the foundation of any electronic flight system.

I mentioned EFBs above as well. This is because the functionality of an EFB constitutes the use of large amounts of continually updated data and what I consider the more challenging aspect of this endeavor. That is to say, building a Primary Flight Display is easy (I already did one). Building a Multi-function Display (MFD) with moving charts, terminal and airspace details, flight planning, traffic, weather, and so on is a little more complex. These are all features found in an EFB, so the EFB is a good stepping stone to a comprehensive EFIS.

That's enough for an introduction to this blog. I hope you enjoy it!