| |
| |
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
MacArthur, Ian (Leonardo, UK) schrieb am Donnerstag, 25. Februar 2021 um 16:00:15 UTC+1:
So I was regenerating the docs on a Msys/mingw build, and I noticed something odd.
TBH, I think it has been doing this for ages, but I usually do this from a script so hadn't really been watching...!
Anyway, when generating the docs for Fl_Preferences, in Fl_Preferences.cxx circa line 177 there's this construct:
The file name is generated in the form <tt>$(path)/$(application).prefs</tt>.
But when doxygen parses this on my build, it is literally expanding $(path) as the $PATH variable from my shell, and $(application) as empty.
The generated docs then have my PATH embedded in the HTML output, which is really not what we want!
I suspect that the construct should really be more like:
The file name is generated in the form <tt>path/application.prefs</tt>.
(Note that path and application are parameters to the constructor method at that point.)
But I don't really know doxygen well, so I may be talking nonsense here!
What do others see? Thoughts?
--
Ian
Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
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/80c9d12c-d5ae-4c6c-a716-e4763de1b78bn%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |
