Internal change

While I continue to refine SnapX.Core, I have given thought to the configuration files and how they're thousands of lines combined.
I've given a lot of thought to how this application configuration will scale in the future. As with many things, the application configuration only seems to grow.

Snapshots

With the new dependence on SQLite, SnapX will be able to take advantage of its ACID compliance to be more reliable.
Additionally, it allows SnapX to track its previous configuration settings all within one SQLite3 file that it can actually do things with. ShareX has snapshots which it calls "backups" by default. However, the program is not really aware of these previous revisions. In the event of a configuration parse error, the program gives up. With the settings being in the database, SnapX can easily go back to a previous timestamped configuration.

History

I've never believed in flat file JSON data storage and I never will. SQLite3 is just simply better. History is going to be viewable via the application. If a user has to go into the application files, I've failed. With SQLite, it will be easier to test.

Portability

SQLite also handles multiple users or threads accessing the data more effectively. With SQLite, concurrent reads are handled well out of the box, and even though SQLite doesn’t support full concurrent writes, it still does a good job with locking to prevent data conflicts, making things much smoother when multiple processes need access. With JSON, I’d have to write my own locking mechanisms, and with the likely inclusion of unthread safe code into SnapX for cross platform screen capture it just makes all the sense to hand the rest of data responsibility to SQLite.

But but SQL is more complicated & not human readable

SQLite clients are readily available. Just to remind you: You cannot open an image file without an image viewer, a pdf file without a pdf viewer, and any "hand rolled" raw text format you built yourself (if the file gets large enough) WILL be unreadable just as much.

I've personally edited JSON files with Notepad.exe before. Never again.

I've personally see some software where its configuration file(s) is like 5 thousand lines of YAML combined. Those are also the same pieces of software that have people selling PRE CONFIGURED CONFIG FILES.

Lastly, once you get the hang of SQLite, backing up or restoring your data becomes trivial. Instead of manually backing up various JSON files, you can just copy the SQLite file and or screenshots, which makes deployment and migrations go over smoothy for everyone.

Migrations for ShareX configurations

I am no fool. I know people want to simply shove their ShareX into somewhere and get the data files into the format SnapX expects. I think that can be done with a simple local only WebAssembly website. I know I can't properly migrate the data files ShareX had within SnapX because Newtonsoft.JSON by default is a lot less strict than what SnapX uses for parsing JSON files (System.Text.Json, modern & fast JSON parser) not to mention it's known to be incompatible with NativeAOT. If you don't know what NativeAOT is, it's the technology SnapX uses to produce binaries that are lightweight & portable.