[haiku-development] Re: ShowImageSettings
- From: Fredrik Modèen <fredrik@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 28 Aug 2012 08:45:52 +0200 (CEST)
> 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 have begun to implement KMessage get* in BMessage. I found that KMessage
uses a template _GetType method in those get* methods and I was thinking
to use the same. I also find that KMessage uses _FindType in find* methods
I was trying to find the implementation of BMessage's all find methosd
(like FindInt64 etc) but I can't find them.
>
>> 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.
So what would be a good name for that? BMessageSave? I will be away the
coming 4 days so not much will happend before that (If I don't get hold of
a wlan and some time :))
>> 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.
Can you clarify that?
> [1]
> http://cgit.haiku-os.org/haiku/tree/headers/private/kernel/util/KMessage.h#n112
>
>
--
MVH
Fredrik Modèen
Other related posts:
