Clemens wrote: > On Sat, 25 Aug 2012 00:47:51 +1200, Fredrik Modèen <fredrik@xxxxxxxxx> > wrote: > > I'm considering to use ShowImageSettings in Bluetooth. > > http://cgit.haiku-os.org/haiku/tree/src/apps/showimage/ShowImageSettings.h > > (if there are no class in BAPI for the same purpose) > > > > That would involve copy it over there. Would it be better to make it part > > of a kit, say support kit? > > > > I don't think I know how to make the class good enough to make it public > > (except perhaps renaming it to BSettings) > > Compared to a BMessage this class is very limited, i.e. not all data types > and no indices are supported. As Axel said, maybe it's better to add some > more convenience method to BMessage directly. +1. KMessage features those as well [1]. > I would also vote to just provide some helper methods to store a BMessage > as an attribute or flatten it to a file, e.g.: > > static BSomeFittingNamespace::SaveToAttribute(const BMessage* msg, const > char* attribute, BNode* storage); > static BSomeFittingNamespace::SaveToApplicationFile(const BMessage* msg, > const char* attribute); > static BSomeFittingNamespace::SaveToFile(const BMessage* msg, BDataIO* > storage); I think the storage kit would be a good place for settings file access functionality. > When it comes to locking maybe a BLockableMessage decorator for a BMessage > would be more versatile? I actually don't understand the class's locking. It does use the lock itself only in the destructor, which I find rather superfluous, since it suggests concurrent access to the object while it is being destroyed, which would be a race condition anyway. The only remaining functionality of the class that doesn't naturally fit anywhere else is the fUpdated flag. A BMessage::operator==() will be a better alternative, if the point is to avoid writing the settings file unnecessarily, though. CU, Ingo [1] http://cgit.haiku-os.org/haiku/tree/headers/private/kernel/util/KMessage.h#n112