Browse interfacekit: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date

[interfacekit] Re: MimeDatabase

From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
To: interfacekit@xxxxxxxxxxxxx
Date: Sat, 17 Aug 2002 04:02:48 -0700

> 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

After trying both, I'm going to stick with the B_SIMPLE_DATA method :-P 
:-) (though I've changed it to B_REG_RESULT just to be explicit about 
what the message really is). Since BMimeType is just passing on the 
status_t value it recieves from the mime manager, it's cleaner to only 
have one message type to deal with. 

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

I'll just leave it as is for now then.

> 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). 

Nice. :-)

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

Will do.

-Tyler

Follow-Ups:

[interfacekit] Re: Icons and BBitmap
From: Tyler Dauwalder

References:
- [interfacekit] Re: MimeDatabase
  - From: Ingo Weinhold

[interfacekit] Re: MimeDatabase

Other related posts: