[interfacekit] Re: Icons and BBitmap

  • From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
  • To: interfacekit@xxxxxxxxxxxxx
  • Date: Mon, 19 Aug 2002 11:46:09 +0200 (MET DST)

On Mon, 19 Aug 2002, Tyler Dauwalder wrote:

> I ran into a bit of trouble whilest working on BMimeType::SetIcon(). My 
> intent was to archive the icon passed to BMimeType, send it in a 
> message to the mime manager (running in the registrar), unarchive it, 
> and let the MimeDatabase class deal with color conversions, etc, etc, 
> before preparing the proper bits to be written to the appropriate icon 
> attribute. That way, all code needing any sort of knowledge about the 
> format of data stored in the database itself is kept in the 
> MimeDatabase class, and not spread all over the place.

Actually BNodeInfo does this conversion and BAppFileInfo will have to do
it as well. So I guess it doesn't make it much worse to do the same in
BMimeType. This has the nice side effect, that in case of a B_RGB32 bitmap
the message sent to the registrar is smaller and the registrar will have
less work to do (no conversion), which increases its responsiveness.

However, don't you have to do a conversion in BMimeType::GetIconForType()
anyway? I mean, you would unarchive the BBitmap and then had to get its
Bits() into the supplied bitmap, preferrably via SetBits(). Er, I
currently don't have BeOS at hand, so maybe I'm wrong and GetIconForType()
also accesses the MIME database directly -- I have the faint feeling that 
it doesn't though.

> The problem I discovered is that R5::BBitmap::Instantiate() is not 
> happy, and by not happy I mean crashing our registrar when I try to 
> call R5::BBitmap::Instantiate indirectly via 
> OBOS::instantiate_object(). Our implementation of instantiate_object() 
> appears to find the proper function in libbe.so (btw, whoever wrote 
> BArchivable deserves a pat on the back; that thing's a monster), but 
> actually calling it leads to a crash. (I thought for a moment it might 
> be that it didn't like the OBOS::BMessage it was being passed, but it 
> looks to me like we're still using R5::BMessage...). I wrote up an 
> empty OBOS::BBitmap class just to see if its Instantiate() function 
> would cause a crash as well, and lo and behold it didn't. Why the 
> difference? I don't know. :-) 

I don't know, what `crashing the registrar' means -- does it really crash
it or just enter the debugger with a message like `You need a running
BApplication to...'? The latter is more than understandable, as we can't
any longer use R5::BBitmap in code that links against libopenbeos, as
OBOS::BApplication will be used instead of the R5::BApplication. And our
BApplication isn't (and won't ever be) able to connect to R5::app_server.

It looks like the very point has been reached, where we -- er, more
precisely, you ;-) -- will need to implement a provisional BBitmap.

> At any rate, I've worked around it for the time being, moving the color 
> conversion code elsewhere (incidentally, converting a B_RGB32 bitmap to 
> a B_CMAP8 bitmap using BBitmap::SetBits is way more involved that it 
> needs to be...). BMimeType::Get/SetIcon() is now finally working, 
> though I plan to add some more tests to be sure all the color 
> conversion code works like I think it should. The other Icon() 
> functions will be tackled next...

Great! :-)

Just to make the confusion perfect: The reason, why you currently can use
R5::BBitmap in libstoragetest is, that it is not directly linked against
libopenbeos (only libstorage is) and therefore uses R5::BApplication.
Isn't this fun. ;-)

CU, Ingo


Other related posts: