Opened 6 years ago

Last modified 2 years ago

#9443 assigned enhancement

API for unified preference storing

Reported by: mks Owned by: nobody
Priority: low Milestone: Unscheduled
Component: Kits/Application Kit Version:
Keywords: Cc: mmadia
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Ticket for something I wrote in the forum before, as requested by mmadia, so I'm quoting myself …

I think application development on Haiku would benefit from a unified and endorsed way for programmers to save application preferences. That's something almost every program needs and yet on many platforms there is no simple API for that. Mac OS X has NSUserDefaults [1] for it and Android uses SharedPreferences [2]. Systems like GSettings in the Gnome world and the Windows registry got the premises wrong and are thus not nearly as comfortable to use.

However, Haiku is "almost there". BMessage can be flattened to and unflattened from files. The data you can store in a BMessage is sufficient for almost any kind of preferences and I think I read somewhere that some programs already use flattened BMessages for that purpose.

What I'd like to see on top of that would be roughly something like a be_app->GetPreferences(), which would return a BMessage and be_app->StorePreferences(BMessage). Didn't put too much thought into the details, but that would be essentially what Android offers. This way the OS could decide *where* and *how* to store the actual physical data. Which would mean 2 things: a) application programmers don't need to think about tedious stuff like storing preferences and can concentrate on more important things and b) it allows for something like OS X's defaults system [3].

The important thing here is, that the application does not decide the where and how, but the OS does, e. g. by using the app signature.

Once applications would use such a system, moving the settings without breaking app compatibility would be an easy thing to do. If one would really want to do that. (That was just the point the forum thread was about)

[1] http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSUserDefaults_Class/Reference/Reference.html [2] http://developer.android.com/reference/android/content/SharedPreferences.html [3] https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/defaults.1.html

Change History (4)

comment:1 Changed 6 years ago by leavengood

+1 to this idea.

While the simple version is decent, it also might be nice to create a BPreferences class which may just wrap BMessage but can provide some nicer semantics. I know quite a few applications within Haiku's repo have already done that, like ShowImage:

http://cgit.haiku-os.org/haiku/tree/src/apps/showimage/ShowImageSettings.cpp

The above makes it such that a default value can be provided when calling for a setting, and that will be returned if the setting was not stored in the settings file. Though I'm not sure if that is better than having all the default values defined in one place. Then of course this leads to whether we should try to mimic the OS X defaults system. I don't know that system well enough to know if it is worth emulating.

comment:2 Changed 6 years ago by axeld

I've already added convenience getters and setters to the BMessage class. All what is left is a BApplication::{Restore|Store}Settings([const] BMessage&) to do that on an application level.

Not sure if there is anything else needed.

You'll probably want to put your own API on top of that anyway, like for example the Mail Kit does (http://cgit.haiku-os.org/haiku/tree/src/kits/mail/MailSettings.cpp).

comment:3 Changed 4 years ago by pulkomandy

Milestone: R1Unscheduled

comment:4 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: newassigned
Note: See TracTickets for help on using tickets.