[interfacekit] Re: MimeDatabase
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Sat, 17 Aug 2002 02:21:02 CEST (+0200)
> I just checked in the beginnings of the mime database code. It
> currently expects to find the database at ~/config/settings/obos_mime
> instead of ~/config/settings/beos_mime (so as not to trash your
> database if I do something stupid ;-), so you'll either need to make
> a
> copy yourself or change the string constant in MimeDatabase.cpp to
> point somewhere else if you feel like playing around with BMimeType
> (though the obos BMimeType tests make a copy if they need to).
Progress... yeah, cool! :-))
I realized, that you are using B_SIMPLE_DATA for the reply messages (I
guess inspired by my mail from june). While that is completely fine in
principle, it is differs from what I used for the roster
implementation, which is B_REG_SUCCESS on success and B_REG_ERROR on
failure. I just found it more explicit to use such (different) message
codes. That's really not a big issue -- I just mention it, in case you
like it too and missed it somehow. :-P
> I have one question currently. I'm a bit perplexed with
> BRoster::_Start/_StopWatching(). I can't figure out what would be
> gained by implementing BMimeType::Start/StopWatching() via said
> BRoster
> calls vs. just using _send_to_roster(,,true) to talk to the
> MimeManager
> directly (the latter being the way I've implemented it currently). As
> best I can tell, that's what BRoster::_Start/_StopWatching would have
> to do eventually anyway, but at the cost of filtering the necessary
> information through a somewhat contrived interface designed to be
> used
> by two notably different monitor services (namely
> BRoster::Start/StopWatching() and BMimeType::Start/StopWatching), and
> with no other apparent gain. Or am I missing something?
Well, BRoster::{_Start,_Stop}Watching may save you a few lines of code
in your implementation, but otherwise I have to agree. Maybe these
methods add other, common information to the message, but currently I
can't think of any.
BTW, I finished the work on BNodeInfo. The tests are complete and the
implementation passes them. The class is not included in the build yet,
as it wouldn't work well with a partial BMimeType implementation. I
will add it as soon as all needed features are available.
While testing BNodeInfo::{Set,Get}Icon() I realized that it doesn't
complain when passing a bitmap with another color space than B_CMAP8.
The tests I'm doing work fine for B_RGB32 and B_MINI_ICON, GetIcon()
crashes for B_LARGE_ICON though. I don't know which is the originally
intended behavior, but I implemented it to deal gracefully with
everything that BBitmap::SetBits() can convert to/from B_CMAP8
(internally B_CMAP8 is still used). For BNode::GetTrackerIcon() I rely
on BMimeType::GetIcon[ForType]() to behave similarly. Therefore it
would be nice, if you could implement it that way. R5 doesn't BTW.
CU, Ingo
Other related posts:
