[interfacekit] Re: Icons and BBitmap

  • From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
  • To: interfacekit@xxxxxxxxxxxxx
  • Date: Mon, 19 Aug 2002 13:30:06 -0700


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

Except it means I end up slinging around a generic data buffer instead 
of a BBitmap object. You're right, though, it's really not a huge issue.

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

Darn, you're right again. ;-) This is a very reasonable argument for 
keeping it like it is now.

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

Nope, it does (access directly). Or at least, that's how I'm planning 
on doing it. 

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

I believe it really crashes. I get the "./obos_registrar has performed 
an illegal operation" alert window (or whatever it says by default) and 
get dumped back at a command prompt.

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

Hmmm, yes... :-) Since I've managed to work around it for the moment 
(and since it looks like it'll be more efficient to keep the workaround 
anyway), I'd rather try and finish up the mime database stuff first. 
But then, yes, I would be happy to tackle it (I do love playing with 
bitmaps), unless there are objections from the IK team...is anyone 
assigned to BBitmap yet?.

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

I thought I understood for a moment :-), but... I *am* using BBitmaps 
in libstorage. MimeDatabase::GetIconData(), which is called by 
BMimeType::SetIcon(), creates a temporary BBitmap that it uses for 
color conversions. Granted, SetIcon() is being called by 
libstoragetest, but it's still sitting in libstorage, which is still 
linked to libopenbeos. You're right, the confusion is nearing 
perfection. :-)

-Tyler

Other related posts: