Right now I've got one last big question to solve: How to consolidate changes made in the graphical form fields with the file-based backend.

In most systems this is a simple matter: Just take, (type-transform,) and save what the user entered (1:1).

In faircamp's case however, each form field (unique and singular in the GUI) maps to any number of (valid or even invalid) declarations of that setting that may exist in the plaintext manifest backend.

So when you e.g. write a setting entered in the GUI back to the manifest ... does it go into line 4 where the setting was declared, or into line 12 where it was also declared a second time, or into line 16 or 23 where it was declared a third and fourth time but with an invalid syntax?

(*/▽＼*)

The good news is that I have all the data structures for this in place already, it's just the consolidation model/algorithm/flow that is a bit challenging, with many settings having different types, requiring different form field/components for each, and different types between the frontend and backend that I need to transform between as well hehe.

But after that it'll be just tying up a thousand loose ends and documenting and publicly testing and packaging and shipping the thing. Piece of cake! ( ^◡^)

#faircamp