[interfacekit] Re: Icons and BBitmap

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

Performance-wise we can improve things even more, by not squeezing the 
bitmap data through a port, but only sending its area ID instead. As 
with all optimizations that can be done later though.

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

Yes, you're right.

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

Well, maybe the unarchiving constructor behaves a bit different. 
However, I think the problem is finally the same one: no connection to 
the app server => no BBitmap.

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

Good deal.

> unless there are objections from the IK team...is anyone 
> assigned to BBitmap yet?.

According to the assignment page Xavier Castellan.

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

Let's try again. :-)
(R5::)BBitmap needs a connection to the R5::app_server and therefore an 
R5::BApplication object, or more precisely a valid libbe::be_app. 
libstoragetest is not linked against libopenbeos and thus a 
BApplication created in it is an R5::BApplication that initializes 
libbe::be_app. That's completely sufficient. It doesn't matter whether 
or not the image (libstorage in this case) containing the code that 
uses BBitmap is linked against libopenbeos, for BBitmap lives in libbe 
and thus any functions/variables accessed by BBitmap code are searched 
only in libbe and whatever libbe is linked against (libroot).

As soon as the entity that creates the BApplication object is linked 
against libopenbeos (before libbe), OBOS::BApplication will be used and 
R5::BBitmap must be left alone. This holds for the registrar for 
instance.

CU, Ingo

Other related posts: