FLTK logo

Re: [fltk.coredev] Fl_Preferences path oddity (needs check)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Fl_Preferences path oddity (needs check) "'Matthias Melcher' via fltk.coredev" Feb 26, 2021  
 

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 ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.