[interfacekit] Re: MimeDatabase

> 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: