If you do that, then it starts looking really similar to BMessage (which does typed key-value storage already). So, why a new class?
And still, you need some application-specific code for things to work. It can be as simple as a list of string constants for the keys, but still you have to write something. So in the end, a specific “settings” class does not simplify this by a lot. And it adds complexity to the API, when BMessage can be used already for the same purpose.
Anyway, if you want to see how this looks in real life situations, there is src/apps/mediaplayer/support/SettingsMessage.cpp and src/apps/webpositive/support/SettingsMessage.cpp
Maybe we should merge these two and move the result to libshared?
Those are a really good starting point, but there is more that can be added to make a settings class more useful:
-Locking procedure so that multiple applications can use the class to read/modify the same settings file without collisions, for example a preflet and server. Also detection of when one app has changed the settings, so other apps can reload the new settings.
-Implement mentioned default/revert option
-Be able to save sets of settings backups. For example, a function SaveBackup(const char* name) will save a copy of the current settings BMessage. You could save multiple backups, recall any backup by name by RestoreBackup(const char* name), get a list of existing backups with BStringList SettingsClass::BackupList().
-Write a parser which converts and prints all saved values to text (could be useful for testing)
Locking: I see why you need that with the notification preferences/server, but I think it is the wrong way to go about it. In such cases, the settings should be managed by the server, and the preferences should message the server to configure it. It should not mess directly with the settings file. Moreover, even if the class implements locking, someone could modify the settings file directly (we run into this fairly often with network preferences). And I don’t think if the network preferences is open, and you change settings in some other way (ifconfig, or manual editing), the network preferences window should be live updating. Likewise, if you open the preferences file in StyledEdit and change the settings elsewhere, StyledEdit should not live update. It should, however, warn that the file has been modified.
Defaults/Revert: as I mentionned earlier, this is easier to implement outside the “settings” class. Look at WebPositive preferences to see how. The idea is to create a static “default” instance (always there), and when opening a preference window, create a copy of the current settings (for “revert”). Then you just need to overwrite the current settings with one of these.
Backups: this seems definitely outside the scope of a settings class. No app I know in Haiku has an use for it, even. Also it is easy to implement with BMessage already (just flatten the message to a file or elsewhere).
Converting to text: BMessage::PrintToStream. And the “message” command line tool.
Unfortrunately the one available in HaikuDepot (2.31) is the broken one. Any of the 3.xx versions will work. I think 3.02 is the one adapted best to PM.
I have the slightly earlier (but working) versions at BeShare
The version 2.32 in haikuports is set as broken, thanks for sharing this one with me.
ps: i’ve been in the Beos community since 1998, and i must say i haven’t used it that much since a long time, and i didn’t know it was written by Jeremy Friesner.
I ran out of time trying to build BeShare after too many HaikuPorter bugs. Did get the older Muscle 3 library compiling, but couldn’t get around HP not working with source in a too deep subdirectory. Work in progress at https://github.com/agmsmith/haikuports
I guess my reasons were that when I went to build the 3.00 version I didn’t know much (anything) about Github PRs and the like, and I was working from the BeOS originals, not the Haikuports sources. So I just published my own sources (on my website and BeShare itself) in hopes that maybe somebody else would rationalize things. Others – like bbjimmy – took those and improved the relation to PM a bit.
AGMS took on the task of merging to Haikuports, but it sounds like he has had difficulties too!
Acutally the best and most usable implementation i could find for storing human readable preferences are the one from Codycam… Since it also encapsulate the values, keeps track of the current value and simplyfies default values (from my point of view).
I have to say that i find it a little intimidating, but that’s to be expected from a newbe like me i guess
the one i find easy to read/understand is the keymapswitcher’s one.
Others – like bbjimmy – took those and improved the relation to PM a bit.
