[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
Other related posts:
