Ground Zero
A bit of a warning up front, this’ll probably be intermingled with some more technical description. I’ll try and kind of explain things in a way that hopefully makes sense, but I won’t guarantee anything 
Okey, okey. So, as my thought process was, “ProffieConfig V2’s gonna be a thing, what should I work on first?!” Given ProffieConfig V1 was my first Desktop application (well… technically that’s not true, SpacenavdRadialMenus came first… but I don’t think it counts), there were plenty of things that I wanted to change architecturally. There were lots of code style and layout things too, but that’s a bit more in the weeds than I want these posts to get into (for now at least).
Foundation Areas of Focus
Among those things, maintenance, updates, and delivery. ProffieConfig V1 was very, very straightforward and pretty basic. I compiled the program, (manually) threw a bunch of files into the resources folder, zipped it, and pushed it up to GitHub (and later my website). Later I got a bit fancy and started making .dmgs for macOS, but it was still the same basic process. I was using a deprecated build system (qmake) because my IDE (Qt Creator) supported it and was easy, and so that whole thing I wanted to rethink… and if I wanted to rethink that it had to come first.
Build System
CMake is an industry standard for C++ build systems, for better or worse.
What is a build system?
Well, I’m glad you asked!
Build systems are a whole bunch of software that you setup to manage your code files as you write them, and structure how things should be built. With C++ especially, the language is very old, and provides a lot of power to programmers. This however means there’s a lot of responsibility (Uncle Ben, is that you?).
So, different things that have to happen to your files to turn them into a real Linux, Windows, or macOS program (and believe me, they differ), and there’s a lot of programs involved in that process. It’s virtually impossible to do it all by hand, so you need a build system to do it for you. There’s still a lot of configuration to do, but it makes everything manageable.
CMake is old, and a lot of people find different things about it annoying, but it’s been around the block a while, and a lot of niche cases and issues have been worked out over the course of its lifetime that simply doesn’t exist with other build systems. Plus, IMO if you’re gonna be a contrarian you’ve gotta have a good reason to… and I didn’t. (And if you’re curious, from using it thus far and learning it, I’ve found it pretty straightforward and, relatively, simple. I’ve been pleased with it and it’s worked well for me)
Updates
Additionally, I wanted to make updates convenient for users…erm, moreso than V1. The best answer V1 had to updating was “well, drag the new files on top of the old ones and let your OS merge them.” That’s certainly inconvenient and less than ideal!
In order to make update sizes smaller if only a certain part of the code is changed, I decided it was reasonable to split parts of the code up into shared libraries. Shared libraries are probably most well-known on Windows as .dlls. They’re often used when, as the name implies, code needs to be shared between multiple applications. By separating it, it can be reused. However, for my case, this has the benefit of breaking apart ProffieConfigV2 into smaller files, which is good for speedy updates.
Then, for the actual updating, since this is largely an educational exercise for myself, I needed to roll (read: program/create) an update system. As I saw it, the easiest way to do this was to use file hashes. File hashes are essentially the result of taking a file, running it’s raw data through a bunch of mathematical operations, and getting back a nice short, unique identifier for that file. They’re extremely common in cryptography and just for data integrity, and it solved a couple of problems.
I didn’t need to keep track of versioning somehow else, and when the files are downloaded, I needed to hash them to verify their integrity anyways (if the file was corrupted during download the hash would be different/invalid), so it was a “two birds with one stone” sort of thing.
So, then updating is pretty simple for the program. Whenever it starts up it (optionally), pulls down a manifest file (A pconf file, which is a simple file format I created for ProffieConfig that probably deserves its own post) from the website (assuming internet is available), reads it, hashes all the program files, checks if there’s updates, and then politely lets the end-user know. If a file is expected but it’s not found, it’s known that it should be added, if a file has a hash that’s not recognized, then it’s considered out of date and needs an update. If I want to add files later, I can, additionally I’ve setup the manifest so different versions (macOS, Linux, Windows) each keep track of their files semi-separately, which is important.
I’m sure there’s more robust systems out there, and I’m sure I’ll find problems with it that require updating the updater (ironic), which will in turn require downloading the new version manually, but if that’s the case, the update system is equipped so it can inform users of any unforeseen breakages that they’ll need to update for.
Ultimately, I’m pretty happy with the solution given I’m completely green to the problem.
Delivery
Well, before things can be updated they have to be installed first!
This is a pretty short little section. macOS by its nature makes applications very easy, and I like it for that. There’s pretty much nothing changing from the .dmg approach I had figured out by the most recent versions of V1. That’s how macOS likes it, it works well, and it makes installation very easy (literally drag and drop)
Windows on the other hand is… annoying and difficult. I tried to look into it a bit and the MSI format is something I decided I didn’t want to deal with. Shopping around, I think what I’ll be using is a program called “Advanced Installer,” which takes care of all the MSI packaging. It has a free version that I think will be perfectly adequate, and it handles installing a Start Menu shortcut, desktop shortcut, moving the files where they need to go (duh), and the MSI is just something that’s familiar and easy for Windows users (relatively).
TL;DR Installation of ProffieConfig V2 will be more conventional, updates will be automated, and my system for handling it all should make my life easier. Excellent!
The Experience
That idea of splitting different things apart comes into play in the UI as well. Instead of a monolithic editor like with V1, which can start to get a bit crowded and confusing, ProffieConfigV2 plans to make better use of a home/launch menu for managing configurations and settings.
At present, the plan is to split up settings for editing wiring (think blades, buttons, OLED, stuff like that), general settings (Volume, idle off time, that sort of thing), presets, and the prop file stuff into their own little window for editing. This will allow me to make UIs that are very much tailored to the goal of each editor, and not need to conform to a general layout. Just like V1, editor windows from multiple different configs can all be open at once.
Additionally, a major shift I hinted at earlier is “global” management of certain features. So, for example, something like bladestyles, which one might want to reuse and edit across configs, will be managed and edited separately from the config, and simply selected in the presets editor. This means that for those settings, you can essentially create a “master” list of all your stuff, and keep track of it all nice and easily. That’s a key design goal with ProffieConfig V2, and my hope is that it’ll make things easier for those who have lots of configs and/or bladestyles, among other things.
The Configuration
If you cannot already tell, ProffieConfig V2 plans to store a lot more information about a config (simple example: blade names) than is intrinsic to a config file. At first I considered trying to use comments to do the job inside a normal config file, but the thing about V1 was that it loaded and used config files the same way it loaded them if they were being imported. There was no distinction. This was great because:
- The savefile
- The output file
- The export file/format
- The import file
- The only file I needed to handle
was the config .h file. That simplified things a lot, but I just don’t think it’s practical for what V2 wants to accomplish. Instead, config files are going to be saved as .pconfs, with a lot of dynamic references to the different global things that can be edited. They’ll only be assembled into .h files for uploading.
However, by nature of still needing to export the .h file to actually make use of the config, users will still have the option to do that themselves. However, as stated above, a .h file can’t carry all the metadata I want. So another export option will be available to users to export a config in a bundle specifically for ProffieConfig. It will ensure that everything needed for a config file (bladestyles and other global configuration bits) are all included in it and include all the metadata needed to import fully into another ProffieConfigV2 (e.g. on another computer) without loosing any of that data.
For the use of ProffieConfig, this bundle will be ideal, and I think there’s a lot of potential for more complete and advanced, seamless sharing with it. I’m sure some people might not want it for a variety of reasons, which is why the alternative will still exist, but I do think it should be pretty neat.
Ideas
The aforementioned approaches and ideas to the fundamental structure and guiding principles of ProffieConfig V2 began to give me a clear direction of how to start developing things in the app.
I’m not quite sure what makes sense to talk about next. I think maybe talking about some UX/UI things might be appropriate?
Comments, Questions, & Concerns
I’d be quite interested to hear people’s thoughts about what I’ve talked about. I’d also love to hear feedback whether people would be more interested in high-level guiding ideas, focusing and drilling down into specific technical challenges I’ve had, and/or just talking about more technical aspects of the program in general.
I’m not super sure what would be interest for me to talk about, so please share!
If there’s anything specific anyone thinks is interesting or they’re curious about, I’d love to hear it, and I’d probably love to share and speak about it. 
Oh, and if there’s any specific feature-requests for ProffieConfig V2. I’ve heard quite a few already, and some things are already kind of set in my mind (or in the code), so you might have to present your case a bit more on certain things, but I’m always open to suggestions!
Otherwise, MTFBWY!
END OF LINE
. Put simply, users create a schematic in order to configure blades, buttons, things like RFID modules, etc. How this whole system works is for another later post, but that idea alone should put into perspective how ProffieConfigV2 is going to be laid out.