|
|
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
On 2/26/2021 10:48 AM, Albrecht Schlosser wrote:
[Opening a new thread with a new subject]
On 2/26/21 10:16 AM Manolo wrote in thread "Doxygen oddity under
Msys\mingw (possibly others!)"
On Thursday, February 25, 2021 at 7:43:10 PM UTC+1 Albrecht Schlosser
wrote:
Hmm, but looking at the docs, this seems to be strange:
Fl_Preferences::Fl_Preferences(
const char * path,
const char * vendor,
const char * application
)
...
"The file name is generated in the form
$(path)/$(application).prefs." [...]
The argument 'vendor' is not mentioned in the docs (file name).
This looks wrong but I can't check this now.
That is strange indeed but not wrong, in the sense that it matches
what is in the source code.
The path of the file reached by this Fl_Preferences constructor is
defined
at line #938 of src/Fl_Preferences.cxx :
snprintf(filename, sizeof(filename), "%s/%s.prefs", path,
application);
This statement is in a member function which receives path, vendor
and application
parameters, but the "vendor" parameter is not used to build the
filename.
Okay, thanks for your research.
This should be checked then:
- is it "correct" (*intended* to be) w/o vendor?
- backwards compatibility with 1.3 ?
- other constructors and paths ?
If it turns out to be wrong and someone has a quick fix, I'd be glad
to read about it here and/or see a commit.
Otherwise we could open a GitHub issue so this will not be forgotten.
Sorry, I'm too busy with other stuff to pursue this myself but didn't
want it to get lost in the noise...
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/8a245f04-8d45-2ab6-47aa-6911c15f20af%40googlemail.com.
[ Direct Link to Message ] | |
|
| |