When I wrote Fl_Preferences in what feels like the 70's (it was probably
in the middle of 90's), there were many conflicting systems across
platforms.
Windows used RegEdit and .ini files. The FLTK format was supposed to be
compatible, but added "./" to section names, which was discovered too
late (it can however *read* .ini files). I decided to use this format
back then, because sections can be hierarchical, the format can be read
very quickly, and it can store all kinds of data including binary. I
wanted to use the exact same format on all platforms, so .ini files can
be exchanged.
Unix back then used the $(HOME)/.something text files or folders for
pretty much everything. I know that this changed massively over the
years, and various registries and app data storage systems were
introduced by various Linux distributions. To stay compatible, I decided
to not touch what I wrote in the olden days. Sure, XML or JSON support
would be nice, but the API is not really set up for that. I don't think
that integrating an XML reader would make much sense or ever be
complete. There are external libraries for that.
MacOS X was still young, but their much more sorted introduction of
application data directories seemed like a good approach, and in order
to get a unique filename for Fl_Preferences, I intended that using
"Fl_Preferences(USER/SYSTEM, vendor, application)" should look something
like this (based on how Apple generates paths):
".../appdata/org.fltk/fluid.preferences" where "org.fltk" would be the
vendor, and "fluid" would be the application. Well, I ended up spending
more time writing the code than writing the docs.
Bill was not happy about this addition IIRC. He wanted FLTK to remain a
pure GUI library, and in retrospect, he was probably right. OTOH,
FL_Preferences helped with typical UI stuff, sometimes as simple as
opening a window again in the same location where the user last closed
it, and that is more or less the intended scope.
This was all well and fine, but I wanted to be able to write a
preferences file just anywhere. So I added "Fl_Preferences(const char
*any_path)", but that sucked, because preferences files were supposed to
have app and vendor name in the first three lines of text. This lead to
the constructor that is mentioned below, where the vendor field is
purely used to write the second line of text in the file header, but it
is no longer part of the filename.
A last word about the API that is relatively uncommon, using
constructors to access sections of the file. Yes, I would do that
differently today. It is possible though, to open a section twice in the
same code and still create a correct .ini file, and users never need to
remember if they must deallocate anything. Much more problematic is any
lack of protection for multithreading or multiple app instances reading
and writing the same file at the same time.
Hoping my ramblings helped a little bit.
- Matthias